Go服务Pod状态为Running但实际挂了，主因是readinessProbe配置错误或ConfigMap更新后健康端点因配置缺失panic；健康路由需在main()初注册、探针逻辑须轻量且解耦配置加载，ConfigMap热更新需fsnotify监听+动态重载，livenessProbe与readinessProbe应分离端点与检查逻辑。
Go服务在Kubernetes里挂了但Pod状态还是Running，十有八九不是代码崩了，而是readinessProbe没配对、或者ConfigMap更新后健康端点因配置缺失直接panic——这两件事经常一起发生，且排查时容易互相干扰。
Go应用的健康检查端点必须独立于业务配置加载
很多Go项目用viper或koanf读取ConfigMap挂载的配置，但把/healthz或/readyz路由注册写在了配置加载完成之后。结果ConfigMap里某个必填字段缺失，viper.Unmarshal()失败，服务启动卡住，readinessProbe连端口都监听不上，kubelet直接判为NotReady。
- 健康检查路由（如
/healthz）应在main()最开始就注册，不依赖任何外部配置 - 探针逻辑里只做轻量级判断：进程存活、端口可连、核心依赖（如数据库连接池）能建连即可，不要调用需要完整配置才能初始化的模块
- 如果必须检查数据库，用
db.PingContext(ctx, time.Second)而非db.QueryRow()，避免因SQL语法或表结构问题阻塞
ConfigMap挂载后，Go程序要主动监听文件变化而非重启
Kubernetes支持ConfigMap热更新（通过volumeMount挂载文件），但Go默认不会自动重载。若程序仍按启动时读取的配置运行，新配置生效后健康端点可能返回错误状态，触发readinessProbe失败。
- 别用
os.ReadFile()一次性读完配置文件就不管了；改用fsnotify监听挂载路径下文件的Write事件 - 收到变更后，用
viper.WatchConfig()或手动触发Unmarshal()，并确保配置校验逻辑不中断健康端点响应 - 注意：ConfigMap更新是原子替换整个文件，不是追加。监听时要忽略编辑器临时文件（如
*~、.swp）
livenessProbe和readinessProbe不能共用同一个HTTP端点
常见错误是给两个探针都配httpGet: path: /healthz，但/healthz里混着“是否能连DB”“是否线程池满”“是否磁盘快满了”等不同维度的检查。结果一次数据库抖动，livenessProbe误判重启，而其实服务只是暂时无法处理请求——这反而放大故障。
-
readinessProbe应检查服务是否准备好收流量：端口监听、DB连接池可用、缓存已预热 -
livenessProbe只检查是否彻底僵死：进程还在不在、goroutine是否全部卡死、内存是否OOM后被SIGKILL - 建议拆成两个端点：
/readyz（含DB Ping）、/livez（只返回200）
用client-go读ConfigMap时，ResourceVersion不匹配会导致配置“看起来更新了但实际没生效”
有些Go服务在启动后用client-go主动轮询ConfigMap，但每次Get()都传空ResourceVersion或缓存旧值，导致反复读到过期内容。此时即使ConfigMap已更新，程序仍按旧配置跑，健康检查返回的状态就不可信。
- 首次
Get()后，把返回对象的ObjectMeta.ResourceVersion存下来 - 后续
Watch()或List()时带上这个版本号，避免重复推送 - 若用
Informers，确保SharedInformer已Run()且HasSynced()返回true再开始处理事件
最常被忽略的是：ConfigMap热更新后，Go程序里已加载的结构体字段不会自动刷新，而健康检查又依赖这些字段做判断——这时readinessProbe返回503不是因为服务坏了，而是它固执地拿着旧配置在“装死”。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
