从单体 Koa 到四服务博客：一次渐进式架构演进
个人博客从一个 Koa 单体，长成「API + 前台 SSR + 后台 SPA + 边缘 AI」四个服务。复盘每一步拆分的动因——不是为了微服务而微服务，而是每次都被一个具体痛点推着走。
架构与工程实践450
# 架构
边缘鉴权：在 Worker 里本地验签 JWT，告别跨境回源
后台点一下「AI 管理」就被登出。排查发现是 Worker 回源到国内服务器验 token，触发了 530。解法不是修网络，而是换架构——把 JWT 验签搬到边缘本地做，彻底不回源。
AI 工程410
webhook 的 fire-and-forget：别让同步拖垮主流程
文章保存成功，就该立刻返回——同步到 AI 知识库这种「副作用」绝不该阻塞它，更不该因为下游挂了而让用户发不出文章。聊聊主流程与副作用的解耦原则。
架构与工程实践370
一套 Docker Compose 同时服务开发与生产：分层覆盖
用三个 compose 文件——基础拓扑、开发覆盖、生产覆盖——让同一套服务定义既能本地一键热重载，又能生产一键带网关和证书部署。讲清分层覆盖的设计与取舍。
云原生与交付400
构建产物与环境解耦：一次构建、多处运行
12-factor 的「一次构建、多处运行」说起来简单，落到前端镜像就是一个问题：配置该在构建期还是运行期注入？我用容器启动时 envsubst 渲染配置的方式，让一个镜像跑遍所有环境。
前端工程260
统一响应与语义化错误码：拦截器 + 异常过滤器
让后端所有出口长一个样——成功走拦截器包装成统一信封，失败走异常过滤器配语义化错误码。前端从此只写一份处理逻辑，再也不用为每个接口的返回结构打补丁。
后端工程360
用 NestJS + Fastify 重写 Koa 博客后端：架构取舍与收益
把一套基于 Koa 的个人博客后端用 NestJS + Fastify 重写，记录模块化分层、统一响应、依赖注入带来的可维护性提升，以及为什么选 Fastify 而不是 Express。
后端工程280
MongoDB 双 ID 体系：为什么同时保留 _id 与自增 id
一篇文章既有 MongoDB 的 ObjectId（_id），又有一个从 1 开始自增的数字 id。看似冗余，背后是对 URL 友好性、外部引用稳定性与查询性能的权衡。
后端工程310
