从零重构个人网站：技术选型与踩坑记录

为什么要重构

老站是一个能跑起来、但经不起推敲的 Next.js 项目：

• 单页面组件 2598 行，改一处要翻半天
• 没有 Git 仓库，任何一次误操作都不可回滚
• 零测试，重构全凭勇气
• 静态资源 106 MB 直接塞在 public/ 里，部署一次要等很久
• 同时存在 PM2 和 systemd 两套进程管理器，互相抢进程
• HTTP 和 HTTPS 的反向代理配置不对称，导致访客看到的是服务器默认页

这些问题单独看都不致命，但叠在一起就是典型的「练手项目」特征。既然要作为作品展示，不如推倒重来。

技术选型

选择成熟开源模板而不是自己从零写，是因为站在巨人的肩膀上更容易看清工程结构——但要真正理解它，必须能说清每一处配置为什么这么写。

内容系统：为什么用 Contentlayer

传统做法是把文章存数据库，然后写后台管理。个人站点完全没必要。

MDX 方案的好处是：

---
title: '文章标题'
date: '2026-09-11'
tags: ['nextjs', '部署']
---

正文里可以直接写 **Markdown**，也可以嵌入 React 组件。

• 文章本身就是 Git 仓库里的文件，天然有版本历史
• 构建时静态生成，运行时不查库，快且稳定
• 想加新文章，只需要新建一个 .mdx 文件

部署架构

自托管的核心链路是：

用户 → Nginx (443/80，TLS 终止)
         └── 反向代理 → 127.0.0.1:3000 (Next.js, PM2 守护)

这里踩了一个很典型的坑：我给 443 端口配好了反向代理，但 80 端口的 vhost 漏了 ProxyPass。结果 HTTPS 访问一切正常，HTTP 访问却落到静态目录，访客看到的是服务器默认占位页。

排查思路是「分层验证」：先确认应用进程本身正常（直接 curl 127.0.0.1:3000 返回 200），再确认反代层配置，最后对比 80 和 443 两份 vhost 的差异。结论是配置不对称。

经验：任何「一套逻辑写两遍」的地方，都要显式对比两份配置是否一致。

这次重构沉淀下来的规范

1. 单文件不超过 300 行，页面不超过 200 行
2. 静态资源超过 500 KB 一律不准进仓库，走对象存储
3. 提交前必须有 lint + 类型检查门禁
4. 进程管理器只能有一套
5. 环境变量不入库，只留 .env.example
6. 上线前跑一遍 Lighthouse，性能分低于 90 不允许发布

下一步

• 补齐单元测试与 E2E 测试，把核心逻辑的覆盖率提到 70% 以上
• 接入错误监控，让线上异常可见
• 用 CI/CD 把「提交即部署」跑通

重构的终点不是「跑起来」，而是「能长期维护」。