好的实现不会依赖用户反复刷新碰运气，而会让每个阶段有明确输入、输出、超时和终态。 liveness 回答重启是否有帮助，readiness 回答现在能否接新流量。把暂时数据库慢放进 liveness 会同时重启所有实例，加重故障。
发布方案必须可复现、可观察并可回退，且回退要包含配置和数据兼容性。健康检查只证明进程存活，核心路由、依赖和后台任务还需单独验收。
先定义系统契约
这项能力横跨客户端、网络与服务端，局部最优很容易制造全局故障。工程决策需要同时约束两端行为、持久化事实和运维预算。
- startup 在迁移或缓存预热期间屏蔽 liveness；readiness 检查本地接流状态和关键依赖预算；liveness 只检测不可恢复死锁。
- 为状态写出唯一所有者、版本号和终态；任何回调只能修改自己创建的版本。
- 上线参数必须有保守默认值、服务端上限和灰度开关，不能把浏览器传来的数字直接当作资源预算。
“Liveness、Readiness 与 Startup：健康检查别互相替代”的交付标准是正常路径可用、异常路径收敛、资源有界，并且用户能理解系统为何采用当前状态。 这样得到的不是演示代码，而是能解释、能降级、能回滚的生产能力。
哪些情况会破坏契约
失败路径需要与成功路径共享同一套状态模型。只弹一个错误提示却不释放资源、不传播终态，下一次恢复就会继承脏状态。
- 探针执行昂贵查询会成为主要负载；所有实例在相同超时临界点同时 not-ready 可能把剩余节点压垮。
- 只修正界面状态而没有清理底层资源，下一次操作继承队列、锁或过期凭据并再次失败。
- 没有背压或配额时，慢消费者会把内存、队列长度与尾延迟一起推高，最后拖累无关用户。
如何逐条验证契约
测试不能以“最后成功了”结束。还要测量经历了多少次副作用、等待多久、是否泄露内容，以及失败后再次执行能否从干净基线开始。
- 注入慢启动、数据库 2 秒抖动、事件循环死锁、磁盘只读和排空，验证只有正确探针变化且编排器动作不会扩大故障。
- 连续执行一百次开始、失败、重试和取消，检查句柄、监听器、队列及临时数据回到基线。
- 用故障注入验证告警先于用户投诉触发，并确认值班人员能从有限证据定位到具体阶段。
完成并不等于主路径跑通，而是每个终态都能对账、每个自动动作都受用户意图约束、每个成本都有明确上限。