就绪探针是轻量 HTTP handler，非 goroutine 轮询；应使用 atomic.Bool 管理状态，在所有依赖初始化验证完成后设为 true，HTTP server 必须在就绪后启动。
就绪探针本质是 HTTP handler，不是后台 goroutine 状态轮询
Go 服务的就绪探针（readiness probe）在 Kubernetes 中通常由一个 HTTP 端点（如 /healthz/ready）提供，K8s 定期 GET 这个路径，返回 200 表示就绪。关键点在于：这个 handler 必须快速响应、无副作用、不阻塞，不能去查数据库连接、不能等 goroutine 启动完成——它只反映“当前是否能安全接收流量”。
- 错误做法：在
/healthz/readyhandler 里调用db.Ping()或等待initCh关闭 - 正确做法：用一个原子变量（
atomic.Bool）或互斥锁保护的布尔字段，在服务真正准备好时设为true，handler 只读取它 - 初始化完成后才启动 HTTP server，避免探针在 server 已监听但业务未就绪时返回 200
用 atomic.Bool 控制就绪状态最轻量且线程安全
Go 标准库的 atomic.Bool（Go 1.19+）是控制就绪状态的理想选择：无锁、零分配、并发读写安全。不要用 sync.Mutex 包裹 bool，也不要用 channel select 模拟，那会增加延迟和复杂度。
典型用法：
var isReady atomic.Bool
func init() {
// 启动耗时初始化（如加载配置、建立连接池）
go func() {
if err := loadConfig(); err != nil {
log.Fatal(err)
}
if err := initDB(); err != nil {
log.Fatal(err)
}
// 所有关键依赖就绪后标记
isReady.Store(true)
}()
}
func readinessHandler(w http.ResponseWriter, r *http.Request) {
if !isReady.Load() {
http.Error(w, "not ready", http.StatusServiceUnavailable)
return
}
w.WriteHeader(http.StatusOK)
w.Write([]byte("ok"))
}
-
isReady.Store(true)必须在所有依赖（DB、Redis、gRPC client 等）完成初始化并验证可用后调用 - 不要在
main()末尾直接isReady.Store(true)—— 那只是“启动完成”，不等于“就绪” - K8s 探针失败时会停止转发流量，但不会重启容器；所以状态必须可逆（比如连接断开后应设为 false，恢复后再设 true）
HTTP server 启动时机决定探针是否“抢跑”
如果 http.ListenAndServe() 在初始化完成前就执行，K8s 可能在 handler 还没注册、或 isReady 仍为 false 时就开始探测，导致大量 503，触发滚动更新失败。
立即学习“go语言免费学习笔记（深入）”；
- 务必把 HTTP server 启动放在初始化 goroutine 之后，或用信号协调
- 推荐方式：用
sync.WaitGroup或chan struct{}等待就绪，再启动 server - 不要依赖 sleep 或重试次数来“等几秒”——环境差异大，不可靠
例如：
readyCh := make(chan struct{})
go func() {
defer close(readyCh)
loadConfig()
initDB()
isReady.Store(true)
}()
// 等待就绪后再启动 server
<-readyCh
log.Println("server starting on :8080")
http.ListenAndServe(":8080", nil)
就绪状态需覆盖运行时退化场景，不只是启动阶段
真实服务中，就绪状态可能随运行时变化：DB 连接池耗尽、缓存集群全部不可达、下游 gRPC 服务批量超时……这些情况都该让探针返回 503，避免 K8s 继续转发请求加重雪崩。
- 定期检查关键依赖健康度（如每 10 秒
db.Stats().OpenConnections），异常时isReady.Store(false) - 注意：检查逻辑本身不能成为瓶颈，超时必须严格控制（建议 ≤ 500ms）
- 恢复逻辑要主动，不能只靠“下次检查变好”，建议加简单退避（如连续 3 次检查成功再
Store(true)） - 日志中记录状态变更（
isReady changed from false → true），方便排查为何流量突然中断
就绪不是一次性开关，而是持续可观察的运行时契约。最容易被忽略的是：把就绪探针当成“启动成功通知”，而忘了它得扛住整个生命周期里的故障传播。
