最直接有效的方式是用标准库 http.ServeMux 注册轻量 /health 端点，返回 200 和 {"status": "ok"}；不依赖第三方包，避免 DB 等外部检查干扰探针语义，健康与就绪探针应仅依赖本地状态（如原子变量）且监听独立端口。
Go 应用暴露健康检查探针，最直接有效的方式是用 http.ServeMux 或 http.HandleFunc 注册一个轻量 HTTP 端点，返回 200 + 简单 JSON（如 {"status": "ok"}），不引入额外依赖，也避免因框架层逻辑干扰探针语义。
为什么不用第三方 health 包？
多数第三方包（如 go-health、uber-go/fx 的 health 模块）会自动集成依赖组件状态（DB 连接、Redis、外部 API），但 Kubernetes 的 livenessProbe 和 readinessProbe 并不需要这么重的逻辑：
-
livenessProbe只需确认进程是否卡死 —— 一个能响应 HTTP 的 goroutine 就足够 -
readinessProbe需判断是否可接收流量 —— 通常只需检查本地监听端口是否就绪 + 关键内部信号（如配置加载完成、gRPC server 启动） - 加了 DB 检查反而会让 readiness 变得“脆弱”：DB 临时抖动导致服务被摘除，但其实应用本身完全健康
如何写一个零依赖的 /health 端点？
用标准库启动一个独立的 http.Server，监听在专用地址（如 :8081），和主业务端口分离 —— 这样即使主服务阻塞（如大量请求积压、GC STW），健康端点仍可响应：
func startHealthServer() {
mux := http.NewServeMux()
mux.HandleFunc("/health", func(w http.ResponseWriter, r *http.Request) {
w.Header().Set("Content-Type", "application/json")
w.WriteHeader(http.StatusOK)
json.NewEncoder(w).Encode(map[string]string{"status": "ok"})
})
go func() {
log.Println("Health server listening on :8081")
if err := http.ListenAndServe(":8081", mux); err != nil && err != http.ErrServerClosed {
log.Fatal(err)
}
}()
}
注意：http.ListenAndServe 是阻塞调用，必须用 go 启动；若需支持 readiness 的“条件就绪”，可将 map[string]string{"status": "ok"} 替换为闭包变量（如 var ready = int32(0)），由主服务初始化完成后原子置 1。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
readiness 探针中如何安全判断“已就绪”？
常见错误是直接检查数据库连接或远程服务 —— 这会让 readiness 失去“本机服务就绪”的本意。正确做法是只依赖本地状态：
- 用
atomic.LoadInt32(&ready)判断关键初始化是否完成（如配置解析、日志句柄就位、gRPC serverStart()返回） - 避免在 handler 中执行任何 I/O（如
db.Ping()），否则探针自身可能超时或拖慢整体响应 - Kubernetes 默认探针超时是 1 秒，而 Go HTTP handler 默认读取 body 超时是 30 秒 —— 若 handler 里意外等待未关闭的 channel，会导致 readiness 卡住并反复重启
在 Kubernetes 中配置 probe 的关键参数
YAML 中不要只写 httpGet.path: /health，必须显式控制行为，否则默认行为容易出问题：
-
initialDelaySeconds: 5—— 给足应用冷启动时间（尤其有 init container 或大配置加载时） -
timeoutSeconds: 1—— 健康端点必须快，设太高会掩盖真实阻塞问题 -
periodSeconds: 5和failureThreshold: 3组合，避免偶发网络抖动误判 - 若用了非标准端口（如上面的
:8081），httpGet.port必须写数字（不是名称），且该端口需在容器ports中声明
真正难的是让 readiness 表达“我准备好处理请求了”，而不是“我能连上 Redis”。这个边界一旦模糊，整个服务拓扑的稳定性就会从根上变脆。
