go语言是构建云原生服务的工具，云原生关键在于无状态设计、环境变量配置、健康检查、优雅退出及k8s生命周期适配；需用net/http实现/healthz与/readyz探针端点并设超时；sigterm处理须用context控制shutdown而非os.exit；viper配置应显式bindenv并禁用automaticenv。
Go 语言本身不提供“云原生服务”这个现成组件，它只是构建云原生服务的高效工具；真正决定是否云原生的，是你的服务如何设计——是否无状态、是否通过环境变量或配置中心获取配置、是否支持健康检查与优雅退出、是否容器化部署并适配 Kubernetes 生命周期。
如何用 net/http 实现符合 Kubernetes 探针要求的健康端点
Kubernetes 的 livenessProbe 和 readinessProbe 默认依赖 HTTP 状态码，必须返回 200 才认为服务就绪或存活。很多 Go 服务只暴露业务接口，漏掉探针端点，导致 Pod 反复重启。
- 在
main()中单独起一个监听/healthz和/readyz的http.Server（推荐用不同端口，如 8081），避免和主服务共用同一套中间件逻辑干扰判断 -
/healthz应只做内存/协程数等轻量检查，不连数据库；/readyz可加入 DB 连接、下游依赖可用性等耗时检查 - 务必设置超时：用
http.TimeoutHandler包裹 handler，防止探针卡住；Kubernetes 默认探针超时是 1 秒，超过即失败 - 示例片段：
http.Handle("/healthz", http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) { w.WriteHeader(http.StatusOK) w.Write([]byte("ok")) }))
为什么 os.Exit(0) 在 SIGTERM 处理中是危险操作
容器运行时（如 containerd）向进程发 SIGTERM 后，期望进程自行清理后退出；若直接 os.Exit(0)，会跳过 defer、关闭 listener、释放连接池等关键收尾动作，造成连接泄漏、数据写入中断、临时文件残留等问题。
- 正确做法是用
context.WithCancel控制主服务生命周期，收到信号后调用cancel()，再等待http.Server.Shutdown()完成 - 必须给
Shutdown()设定超时（如 10 秒），否则可能无限等待未完成请求；超时后才调用os.Exit(1) - 不要忽略
http.Server.Shutdown()的返回值，它可能返回context.DeadlineExceeded，需记录日志
使用 viper 读取配置时，为何环境变量优先级常被误设
云原生场景下，配置应按「环境变量 > 配置文件 > 默认值」顺序覆盖，但 viper 默认不启用环境变量自动映射，且 AutomaticEnv() 不等于「按需加载」——它会把所有键转为大写下划线格式，容易和真实环境变量冲突。
立即学习“go语言免费学习笔记（深入）”；
- 显式调用
viper.SetEnvPrefix("APP")，再用viper.BindEnv("database.url", "DB_URL")精确绑定，避免模糊匹配 - 禁用
viper.AutomaticEnv()，改用viper.ReadInConfig()+ 显式BindEnv，否则viper.Get("log.level")会去查LOG_LEVEL，而你实际设的是APP_LOG_LEVEL - 配置项名统一用小写+点号分隔（如
cache.ttl），环境变量名则严格对应前缀+大写+下划线（如APP_CACHE_TTL=30）
云原生不是加几个注解或换套 SDK 就能实现的；真正的难点在于对信号处理、配置加载时机、HTTP 生命周期、容器启动/停止语义的理解是否到位——这些地方出错，服务在本地跑得好好的，一上 K8s 就反复 CrashLoopBackOff。
