先用一句话判断故障类型
如果是“能发布但打不开”，先看路由和缓存；如果是“根本没产物”，先看构建；如果是“偶发失败”，优先怀疑环境漂移、速率限制或外部平台不稳定。
1先确认报错出在构建前还是构建后
2再确认失败是稳定复现还是偶发
3最后决定修复、重试还是回滚
部署问题
部署出问题时，最有效的办法不是盯着“最后一步挂了”，而是像发布工程师那样把链路拆成 构建、产物、上传、路由、缓存、回滚 六段，逐段确认到底是哪里失真。
最常见 404 来源
- 最新链接还没完成同步
- topic 路径拼写不一致
- 静态产物没写到预期目录
- 缓存仍指向旧版本
最常见发布失败来源
- 单页 HTML 生成不完整
- 脚本依赖的环境变量缺失
- 外部发布平台限流或短时异常
- 脚本成功退出前没有真正拿到最终 URL
建议排查顺序
- 看脚本 stdout，先拿到真实发布结果。
- 如果用户问 404 / 为什么失败，再追最近日志。
- 确认当前 topic 的
latest.html、history.html是否存在。 - 若本次失败但历史可用，优先给回退入口，而不是空等。
一个稳妥的发布习惯
- 先生成单文件页面：确保最终产物自包含、无外链依赖。
- 再执行统一脚本：避免人工走多套发布路径。
- 最后只认脚本输出的 URL：不要手拼链接，不要猜。
回退策略
如果这次没落地，不要硬说成功。最实用的做法是直接给出该 topic 的 latest.html 与 history.html，让使用者至少有稳定入口，再继续修复。
一句话总结
部署问题本质上不是“脚本有没有跑”，而是“用户最终能不能稳定打开正确版本”。