改一个条目重建全站：目录站的静态化与发布流水线该怎么搭
改
几千个页面的目录站，全量构建一次可能要几分钟；几万个页面就要几十分钟。这个时长本身还能忍，真正的问题是它带来的副作用。
图片来源：网络，版权归原作者所有，侵权请联系删除
全量重建的三个副作用
- sitemap 里所有页面的 lastmod 全变了。搜索引擎看到的是全站同时更新，实际上你只改了一个条目。这个信号发多了，lastmod 就失去了参考价值
- CDN 缓存大面积失效。全站重新发布意味着大量资源要回源，回源压力上去了，还可能触发限流
- 构建期间线上状态不确定。如果直接生成到线上目录，用户会看到生成到一半的站点
这三个问题在页面少的时候不明显，量一大就全部暴露。
增量构建：按粒度切
核心思路是——改什么，就只重新生成受影响的那部分。目录站的依赖关系其实很清晰：
| 改动 | 需要重新生成 |
|---|---|
| 单个条目内容 | 该条目页 + 所属分类页 + 相关列表页 |
| 新增/下架条目 | 同上 + sitemap 对应分片 |
| 分类结构调整 | 全部分类页 + 首页 + 导航相关页面 |
| 模板改动 | 使用该模板的全部页面（这一类没法增量，按计划执行） |
前两类是日常操作，做到增量就能覆盖九成以上的发布场景。第三类按周或按月发生，可以接受慢一点。第四类本来就该走计划窗口，不要混在日常发布里。
发布要原子：先建新目录，再切
不要直接把生成结果写到正在提供服务的目录里。正确顺序是：
- 构建到带版本号的新目录（比如 release/20261023-01）
- 在新目录上做自检：关键页面状态码、sitemap 可访问、条目数量对得上
- 自检通过后，把站点根目录的软链接或配置指向新目录
- 保留上一个版本，出问题直接指回去
这样发布切换是瞬时的，回滚也是瞬时的。代价只是磁盘上多放一到两个版本，对目录站这种纯静态内容来说几乎可以忽略。
构建产物不止 HTML
一次完整的构建应该顺带产出这些东西，别让它们各自为政：
- sitemap 分片。超过一定规模要拆成索引文件加多个分片，分片里只更新有变动的那一个
- RSS 或 Atom。最新条目的订阅源，是第二条发现通道
- 死链清单。构建时顺带校验条目链接可达性，不可达的输出成报表
- 统计基线和校验和。页面总数、条目总数、关键页面的内容指纹，用于发布后比对
第四项常被漏掉。有了它，发布之后跑一遍校验和，能在几分钟内确认"线上确实是这一版"，而不是靠肉眼看首页。
触发方式：定时还是事件
两种都要有。定时构建处理周期性的任务（比如每日汇总页、排行榜、失效条目巡检结果）；事件构建处理即时操作（条目通过审核、条目被下架）。
事件构建要注意合并。审核高峰期可能一分钟内有几十个条目通过，如果每个都触发一次构建，构建队列会堆积。做法是设一个短窗口（比如 30 秒）做批量合并，窗口内的一次构建处理所有待发布条目。
发布后要做的事
- 提交变动页面的 URL 给主动推送接口，只提交变动的，不要每次全量推
- 清除 CDN 上对应页面的缓存，用目录级或 URL 级清除，别清整站
- 对比新旧版本的页面指纹，确认没有意外的大范围变化
- 监控半小时内日志里的 5xx 比例
关键指标：一次条目级发布的耗时应该控制在分钟级，影响页面数应该是个位数。如果每次改一个条目都要动几百个页面，说明依赖切得不够细。
失败回滚的判定条件
提前定好什么情况必须回滚，别在现场讨论：
- 自检阶段关键页面状态码非 200
- 页面总数与上一版差异超过设定比例
- 发布后 5xx 比例超过阈值并持续
- sitemap 或 RSS 不可访问
定好之后写成脚本自动判定。人工判断在深夜发版时是不可靠的。
静态化给目录站带来的是速度和稳定，但前提是构建和发布这两件事做得足够细。切分依赖、原子切换、自动回滚——这三件事做好，静态化才真正省事。