很多团队会把发布成功定义成一句很低的标准：服务没挂、页面能打开、报警没响。
但真正成熟的发布体系追求的是另一件事：
用户几乎感知不到你刚刚发了一个版本。
零停机部署关注的是“切换瞬间”，灰度发布关注的是“放量路径”
这两个概念经常一起出现，但并不完全相同。
- 零停机部署解决的是新旧版本切换时服务不中断
- 灰度发布解决的是新版本如何逐步放量、逐步验证
如果只做零停机切换，没有灰度验证，服务虽然不会瞬断，风险仍然会一次性暴露给所有用户。
先建立版本切换的最小安全条件
要真正做到零停机，团队至少要先回答：
- 新版本何时算 ready
- 老版本何时允许摘流
- 会话、缓存和静态资源是否兼容
- 数据结构变更是否支持双版本共存
这些问题不清楚，所谓零停机通常只是“碰巧没出事”。
灰度发布要绑定可观测信号，而不是只绑定比例
灰度发布最常见的误区，是把重点放在 5%、10%、20% 这些比例上。
但比例本身没有意义，关键是每一步放量都依据什么判断。
更稳的信号通常包括：
- 错误率
- 延迟变化
- 关键接口成功率
- 关键转化路径指标
如果没有这些信号，灰度只是一种更慢的全量发布。
Nuxt 应用发布时要特别关注哪些兼容问题
Nuxt 项目常见的风险点包括：
- 新旧版本静态资源 hash 不一致
- SSR 与客户端 hydration 结果不一致
- 环境配置切换后行为改变
- API 响应结构更新导致旧页面失效
这也是为什么零停机与灰度发布不能只由平台层决定，应用层也必须配合设计。
常见失败案例：灰度做了，问题还是在全量后才暴露
这类情况通常不是灰度没做，而是灰度维度太粗：
- 只看服务层指标，不看业务指标
- 只看平均值，不看特定设备或路由
- 只灰度流量，不灰度依赖与配置
结果是前期看起来正常，真正放量后才出现结构性问题。
一个更稳的发布路径
推荐的做法通常是：
- 先保证新旧版本能短时间共存
- 用 readiness 和健康信号决定切换时机
- 先灰度低风险流量，再逐步放大范围
- 每一步放量都绑定明确观测指标和回滚门槛
- 回滚路径必须预先演练，而不是出事后临时决定
一份可直接复用的检查清单
- 新旧版本是否支持短时间共存和快速切换
- readiness 门槛是否真实反映可用状态
- 灰度步骤是否绑定错误率、延迟和业务指标
- 静态资源、缓存和 API 变更是否考虑了兼容窗口
- 回滚机制是否简单、明确并经过演练
总结
零停机部署与灰度发布的价值，不是让发布流程看起来更专业，而是让变更风险被拆小、被看见、被快速回退。只要切换条件、观测指标和回滚路径一起设计，发布就会真正变稳。
进一步阅读：
