首页能打开，数据库操作却失败，说明健康接口检查得过浅。反过来，一个可降级的依赖短暂故障也不一定需要重启整个应用。
存活检查回答进程是否需要重启，就绪检查回答是否应该接收目标请求。依赖探针、初始化状态和关键业务查询可以提供不同证据，但探针本身也会产生负载。
一、问题的范围与前提
接口由请求身份、参数语义、授权条件和结果状态共同构成。HTTP 层成功只描述传输与响应，业务处理还可能处于受理、执行或等待确认阶段。将外部输入转换为内部对象以后，仍需核对类型、范围和当前状态，不能因为 JSON 能解析就直接使用。
二、技术分析与方案取舍
如果缓存故障可以降级，存活探针就不宜因缓存不可达不断重启应用；就绪是否关闭也取决于哪些请求仍可处理。初始化中的模型则应在目标模式准备好之前明确未就绪。探针自身有时间预算和频率，复杂全业务测试不必每秒跑。状态要和流量入口或运维动作对应，而不是只有绿色图标。
应用入口应有明确大小、时间和并发预算。正常和异常返回都遵循稳定结构，调用方可以据此选择等待、查询、修正或重试。涉及写入与外部动作时，为同一业务意图提供稳定身份，并在持久化边界内管理已受理结果，防止回执丢失造成重复执行。
三、实现与排查的顺序
- 列出启动准备条件。
- 区分必要与可降级依赖。
- 给探针设置有界超时。
- 将状态与入口流量策略对应。
按这个顺序保留中间结果，可以区分输入条件、处理过程和最终输出。前一阶段的条件不成立时，先解释对应错误，再继续后面的试验；单次返回成功不足以覆盖整条链路。
最小示例
1
2
3
存活：主进程是否能继续提供服务
就绪：必要依赖和初始化是否满足
验收：一次目标业务是否得到正确结果
三层可以有不同判断。探针需要预算和访问限制，unhealthy 不自动等于重启，依赖可降级时也不能简单让所有服务退出。
四、验证和结果解释
至少关联请求到达、关键依赖调用和处理结果。日志记录标识与阶段即可，密码、Cookie、token 和原始敏感请求不应进入公共记录。排查时用同一入口比较请求与响应，再结合后端证据，避免页面统一错误文案掩盖具体原因。
| 需要验证的结果 | 保留的对照 | 不能由此推出的结论 |
|---|---|---|
| 初始化未完成时不会宣称就绪 | 固定输入与配置、对应输出 | 一次成功代表所有条件成功 |
| 可恢复依赖故障不会形成重启风暴 | 中断前后状态与错误阶段 | 没有报错代表结果正确 |
| 健康接口不暴露内部凭据 | 恢复后的同条件复测 | 临时恢复代表根因已经消失 |
验收除了正常返回，还包括重复提交、格式错误、依赖超时与调用方取消。系统应能对未知结果查询或恢复，而不是把每个超时都当成未执行。恢复范围尽量匹配故障，防止一个依赖异常引发所有服务同时反复重启。
五、适用边界与结论
一次成功探针不证明所有业务正确，复杂检查也不宜高频执行。恢复动作必须匹配故障范围，避免扩大影响。
这条路径把“列出启动准备条件”与“将状态与入口流量策略对应”连在一起，中间保留可复查的条件。实施时优先确认“初始化未完成时不会宣称就绪”，再检查“健康接口不暴露内部凭据”；两者都满足，才能在当前样本与配置范围内评价方案。设备、数据或软件版本改变以后，相关假设需要重新验证。
