从零复刻一座教堂：一次对耐心的工程练习

我有个业余项目：swedenborgwork.cn 的全栈重构。 原站是 .NET 6 + Furion + SQL Server 跑在 Windows 上的，我没有改需求， 只是把它用 React / NestJS / PostgreSQL 重写了一遍，并部署到 Linux。

动机很单纯

不是为了性能，也不是为了简历上多一行。

是因为我想知道自己能不能独立完成一件跨越三年的事—— 从数据模型迁移、前后端重写，到部署、监控、修 bug。

这个项目里的每一个决定都是我自己拍的板，也只有我自己会为它负责。这种感觉在工作中很难获得。

技术上并不炫技

重构本身没什么壁垒：SQL Server → PostgreSQL、全量接口重写、nginx 部署、 把整站从 Windows Server 搬走。每一项都是成熟技术。

真正花时间的是那些没人会写进简历的细节：

• Windows 和 Linux 的换行符差异会让一个每日清缓存脚本静默不执行
• 上传中文名附件时，busboy 用 latin1 解析 filename 导致正文乱码
• 磁盆 fetch 缓存无限增长 → 句柄耗尽（EMFILE）→ 整站变成无样式裸页面

最后这个 bug 我查了很久。线上表现是「网站突然坏了」，但根因在缓存设计上。 当时的感觉像是：生产环境教会我的东西，比任何一本书都多。

我从中学到的

1. 可观测性不是可选项。 出问题时能不能快速定位，取决于你平时留了多少痕迹。 我现在写每个修复都会保留「作废的推断」——回头看很有价值。
2. 静默失败比崩溃可怕。 那个清缓存脚本失败了三个月没人知道，因为它「没报错」。
3. 性能优化常常是架构问题。 句柄泄漏不是加个 close() 能解决的，是缓存边界没设计对。

为什么放在「爱好」栏目

因为它不该被当成工作。

它没有 KPI，没有 deadline，没人催。它的唯一评价标准是我自己下次还想不想继续维护它。

我把它放在这里，是想提醒自己：工程能力的一部分， 来自那些没人要求你做、也不会写进简历、但你依然想把它做好的事情。