答案是服务状态切换不能只改一个变量赋值ishealthy，因为http返回200不等于能安全接流或放手，readiness接口必须真实验证db、grpc、缓存等关键依赖并返回503；liveness与readiness须分离（/healthz vs /livez），避免数据库抖动引发误重启；状态变更需严格时序配合sigterm、shutdown、反注册、gracefulstop等步骤，漏一环即导致幽灵实例或流量丢失。
服务状态切换为什么不能只改一个变量
直接给 isHealthy 赋值 true/false 是最常见也最危险的做法。Kubernetes 的 readiness probe 会轮询你的健康接口，但 HTTP 层返回 200 并不等于流量已安全切走——gRPC 连接还在、Kafka 消费者没停、DB 连接池里还有活跃 query，下游服务可能正往你这儿发请求。状态切换不是“告诉别人我好了”，而是“确保我真能接住、也能安全放手”。
readiness 接口必须反映真实资源就绪状态
很多团队把 /healthz 写成固定返回 {"status":"ok"}，这等于关掉了 Kubernetes 的流量调度能力。真正的 readiness 检查必须同步验证关键依赖：
- DB 连接池是否可 ping（
db.PingContext(ctx)，非阻塞） - Consul/etcd 注册是否成功（
client.Status().Leader()或 key TTL 是否刷新） - gRPC 客户端连接是否 Ready（
conn.GetState() == connectivity.Ready） - 本地缓存初始化是否完成（
cache.IsReady()）
任意一项失败，就该返回 503，哪怕 HTTP server 已监听。否则 K8s 会提前把流量导进来，触发 RST 或超时。
liveness 和 readiness 必须分离且逻辑互斥
共用一个接口、或只靠超时判断 liveness，是平滑切换失败的高频原因：
-
/healthz是 readiness：检查“能否服务新请求”，失败则从 Endpoints 移除 -
/livez是 liveness：检查“进程是否卡死”，失败则触发 Pod 重启
比如 DB 网络临时抖动，/healthz 应返回 503（暂停导流），但 /livez 必须仍返回 200（避免误杀 Pod）。如果两者逻辑混在一起，一次数据库抖动就会导致整个服务滚动重启。
状态切换要配合信号与反注册时序
状态变更只是表象，背后必须联动 shutdown 流程：
- 收到
SIGTERM后，先置isReady = false，再立即触发http.Server.Shutdown() -
Shutdown()返回后，才调用 Consul 反注册（client.KV.Delete(...)） - 反注册成功后，再关闭 gRPC server（
grpcServer.GracefulStop()） - 最后等所有 goroutine 退出（
wg.Wait()）才os.Exit(0)
顺序颠倒或漏掉任意一环，都会留下幽灵实例——K8s 认为你已下线，但旧进程还在收请求，或者新实例已上线却因反注册未完成被上游忽略。
真正难的不是写个布尔开关，而是让每个组件的状态变更在时间轴上严格对齐：HTTP 层、gRPC 层、消息层、注册中心、客户端感知，全部必须在同一窗口内完成切换。漏掉一个时序点，平滑就变成“看起来平滑”。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
