把发布脚本变成质量闸门:Docusaurus 站点在 build 前该挡住什么
· 阅读需 5 分钟
以前我对博客发布脚本的要求很低,能把 build -> 上传 -> reload 跑通就算不错。等 blogV2 的文章越来越多、迁移批次越来越频繁以后,这条认知很快就被现实打掉了。因为对内容站来说,最贵的成本不是手工上传慢十秒,而是坏内容已经被发到线上以后,才发现链接错了、description 烂了、文章根本还是半成品。
以前我对博客发布脚本的要求很低,能把 build -> 上传 -> reload 跑通就算不错。等 blogV2 的文章越来越多、迁移批次越来越频繁以后,这条认知很快就被现实打掉了。因为对内容站来说,最贵的成本不是手工上传慢十秒,而是坏内容已经被发到线上以后,才发现链接错了、description 烂了、文章根本还是半成品。
Nginx 给 Node 服务做反向代理是很常见的组合,但很多项目把配置写到“能转发请求”就停了。真正上线跑一段时间后,问题通常出在另一层:Node 应用到底有没有拿到正确的客户端信息,日志又能不能支撑定位问题。
很多 Node.js 项目在开发阶段都很轻快,但一到线上就开始暴露另一个问题:服务虽然能跑起来,可一旦遇到重启、日志、端口暴露、反向代理这些现实问题,整套方案就显得不够稳。
Docker Compose 刚开始用的时候特别有吸引力,因为你很快就能把 Node.js 服务、Nginx 代理、数据库一起拉起来。可 2017 年我自己真正把它放进开发流程后,最大的感受不是“真方便”,而是“边界太容易乱了”。
Nginx 反向代理 Node 服务时,很多问题表面上都像“接口有 bug”。
可 2017 年我自己在处理代理和部署问题时,越来越多时候发现,根因其实不在业务代码,而在请求经过 Nginx 之后,有些关键信息没有被完整传下去。