/healthz仅暴露状态，自愈需外部协调器或内部goroutine触发；/readyz负责依赖检查并返回503；应缓存探测结果、状态驱动恢复、幂等操作且禁用os.exit。
健康检查接口本身不能“自愈”，它只负责暴露状态；真正的自愈动作必须由外部协调器（如 Kubernetes）或服务内部的独立 goroutine 主动触发 —— 否则你写的 /healthz 永远只是个只读仪表盘。
为什么 /healthz 返回 200 也不代表服务真能干活
很多团队把 /healthz 写成固定返回 {"status":"ok"}，结果数据库连不上、Redis 超时、goroutine 泄漏几千个，探针照样绿。Kubernetes 看到 200 就认为“活着”，继续转发流量，最终雪崩。
-
/healthz应只检查本地进程状态：HTTP listener 是否可 accept、关键 channel 是否未阻塞、runtime.NumGoroutine()是否异常飙升 - 依赖检查（DB、Redis、下游 gRPC）必须放在
/readyz，且超时严格设为 2–3 秒；失败就返回 503，让 Kubernetes 停止转发新请求 - 不要在 handler 里调用
db.Ping()这类阻塞操作 —— 它会拖慢整个探针，导致探测超时误判；应提前轮询并缓存结果
如何让 Go 服务“自己动手恢复”，而不是等 K8s 杀掉重试
真正可控的自愈，是服务启动后自己开 goroutine 定期执行恢复逻辑，而不是被动等外部信号。关键在于状态驱动 + 可逆操作。
- 用
sync.Map或原子变量维护全局服务状态（如isReady），所有检查项更新它，/readyz直接读取 - 启动一个
time.Tickergoroutine，每 5 秒调用db.PingContext(ctx, 2*time.Second)；连续 3 次失败，就执行db.Close()+reconnectDB() - 恢复动作必须幂等：重连 DB 前先判断是否已连接；加载配置前比对 etag 或 checksum，避免重复 reload
- 禁止在恢复流程中调用
os.Exit()或panic()—— 这会让进程瞬间消失，丢失正在处理的请求
Go 语言特性怎么被误用成“假高可用”
很多人以为用了 goroutine、channel、context 就天然高可用，其实恰恰相反：用错反而放大故障面。
- 在
/healthzhandler 里起 goroutine 去查 DB？—— 探针并发一高，瞬间打满连接池，自己把自己干趴 - 用
select { case 但没设 timeout？—— 上下文永远不 cancel，goroutine 泄漏，内存缓慢上涨 - 所有错误都
log.Fatal()？—— 一次 Redis 超时就 kill 整个进程，而本可降级为本地缓存或空响应 - 用
recover()捕获 panic 后直接 return，却不重置状态？—— goroutine 卡死，服务标记为 ready，但实际已不可用
别忽略 Docker/K8s 层的配合细节
Go 代码写得再好，容器层配置错一步，自愈就失效。最常踩的坑不是代码，而是环境。
- Dockerfile 里没加
HEALTHCHECK --interval=10s --timeout=3s --start-period=30s CMD curl -f http://localhost:8080/healthz || exit 1，Docker 就不知道容器是否真活 - Kubernetes 的
livenessProbe和readinessProbe都指向同一个/healthz？—— 该杀的时候不杀，该剔除的时候不剔除 -
terminationGracePeriodSeconds设成 1，但srv.Shutdown()需要 10 秒清空连接？—— 请求被硬 kill，用户看到 502 - 没挂载
emptyDir或清理/tmp，重启后残留锁文件或 socket，新进程起不来
自愈不是写个 for range ticker.C 就完事，而是每一层（Go runtime、HTTP handler、依赖客户端、容器编排）都要对“状态变化”有明确响应路径。最容易被跳过的，是恢复后的状态校验 —— 重连 DB 后，你得立刻再 ping 一次，确认它真回来了，否则又陷入假循环。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
