滚动发布把 8 个 Pod 全部重建，熔断器计数清零，新 Pod 对已经挂掉的库存服务重新发起全量调用。发布后 2 分钟库存服务错误率从 12% 涨到 40%，恢复时间被拖长。日志里能对上时间点，这种反而好排。
熔断状态存在进程内存里，Pod 重建就没了。发布窗口又正好在依赖故障期间，新实例没有任何历史信息。这一点先确认清楚，后面就不用反复试。
kubectl rollout status deploy/order --timeout=120s kubectl get pods -l app=order -o wide curl -s localhost:8081/actuator/health | jq '.components.circuitBreakers'
这次卡住的地方就在「熔断状态清零」这一环，单独把它拎出来验证，别和其他改动混在同一次发布里。先做最小复现，能稳定跑出来的问题，排查成本会低一个数量级。
处理上按这个顺序：发布前确认依赖健康 依赖异常时暂停滚动；启动时先读一次依赖健康检查 不健康直接预热成 OPEN；把熔断状态外置到 Redis 或者共享指标 供新实例参考；发布策略改成先停后起 减少同时冷启动的实例数。
结果对不对很好判断，依赖故障期间发布不会再放大下游错误率，新 Pod 启动后 10 秒内熔断状态和旧实例一致。