Go服务TCP探针不可靠，因仅验证端口监听，无法反映业务就绪、进程卡死或依赖可用性；应改用语义清晰的HTTP探针（/livez检查内部状态、/readyz检查带超时的依赖），并监听0.0.0.0而非localhost。
Go 服务用 TCP 探针基本不可靠，除非你明确只关心端口监听本身——它无法反映业务是否就绪、进程是否卡死、依赖是否可用。
TCP 探针在 Go 场景下为什么几乎没用
TCP 探针本质只是 kubelet 尝试对容器 IP + 指定端口发起一次 connect() 系统调用。只要 Go 进程已调用 net.Listen 并成功绑定端口（哪怕还没 accept 一个连接），TCP 探针就永远返回成功。
这意味着：goroutine 全部阻塞、HTTP 路由未注册、数据库连接池空、甚至主 goroutine 已 panic 但监听器还在——TCP 探针照样绿灯放行。
- Go 启动后几毫秒内就完成
Listen，initialDelaySeconds很难设得合理：设太短，可能 bind 还没完成；设太长，又浪费就绪时间 - 无法区分“端口开着”和“服务能干活”，和 Kubernetes 健康检查的原始目标（感知真实可用性）背道而驰
- 一旦配合
livenessProbe使用，等于放弃进程存活判断；配合readinessProbe使用，则等同于把流量导给一个“假在线”的实例
什么时候可以考虑 TCP 探针（极少数例外）
仅当你的 Go 服务是纯 TCP 长连接代理类程序（如自研 LB、TLS 中继），且不暴露 HTTP 端点、也不依赖任何初始化逻辑时，TCP 探针才勉强有意义。
立即学习“go语言免费学习笔记（深入）”；
即便如此，仍需注意：
- 必须确保
livenessProbe.tcpSocket.port和 Go 实际监听的端口完全一致，不能写错或被环境变量覆盖 -
timeoutSeconds应 ≤1，避免kubelet在宿主机网络抖动时误判（TCP connect 超时默认可能达数秒） - 不能和
httpGet或exec混用在同一探针字段——YAML 解析会静默忽略后者
Go 服务该用什么替代 TCP 探针
绝大多数 Go 服务应放弃 TCP 探针，改用 HTTP 探针并暴露语义清晰的端点：
-
/livez：只检查内部状态（如atomic.LoadInt32(&live)），响应必须 ≤100ms，不访问任何外部资源 -
/readyz：可检查 DB、Redis、配置加载状态，但每个依赖超时严格控制在500ms内，并用context.WithTimeout包裹 - 两个端点都必须绕过所有中间件（Gin/Echo 的日志、鉴权、recover），直接注册到
http.ServeMux - 对应 YAML 中的
livenessProbe.httpGet.path和readinessProbe.httpGet.path必须分别指向这两个路径，不能共用
最容易被忽略的兼容性坑
Go 服务监听地址默认是 localhost:8080，但 kubelet 是从宿主机网络命名空间发起探测的，必须监听 0.0.0.0:8080 才能被 TCP 或 HTTP 探针访问到。
这个错误不会报错，只会让探针持续失败——因为 kubelet 连的是 Pod IP，而 Go 只绑了 loopback。
启动代码里漏掉这句：http.ListenAndServe("0.0.0.0:8080", mux)，比配错所有参数更致命。
