生产环境必须在main()早期统一校验环境变量，用封装函数处理缺失/非法值并禁止fallback，默认缺失关键变量应log.Fatal退出；禁用viper热重载，配置随镜像打包；用build tags编译期隔离生产逻辑；HTTP服务启动前须同步校验监听地址、TLS配置和健康端点。
如何用 os.Setenv 和 os.Getenv 安全读取生产环境变量
硬编码配置或把敏感信息写进代码里，在生产环境等于主动开后门。Golang 本身不提供“配置文件自动加载”机制，所以必须靠自己控制环境变量的注入与读取时机。
关键不是“能不能读”，而是“什么时候读、读不到怎么办、读错类型怎么兜底”。比如 os.Getenv("PORT") 返回的是字符串，但 HTTP server 启动需要 int，直接 strconv.Atoi 而不检查错误会导致 panic。
- 所有环境变量应在
main()最早阶段读取并校验，避免在深层函数中零散调用os.Getenv - 用封装函数统一处理缺失/非法值，例如：
func GetIntEnv(key string, def int) int { if v := os.Getenv(key); v != "" { if i, err := strconv.Atoi(v); err == nil { return i } } return def } - 生产环境禁止 fallback 到开发默认值（如
def: 8080），缺失关键变量应直接log.Fatal并退出
为什么不要用 viper 自动监听配置文件重载
很多教程推荐用 viper 管理配置，但它默认支持的 viper.WatchConfig() 在生产环境是危险操作：文件热重载可能让数据库连接池大小突变、JWT 密钥轮换不一致、甚至触发 panic（比如重载时结构体字段类型不匹配）。
真正的生产部署依赖不可变基础设施——配置随镜像打包，重启应用才是唯一受控的变更方式。
立即学习“go语言免费学习笔记（深入）”；
- 若坚持用
viper，禁用所有自动重载：viper.AutomaticEnv()可以保留，但必须关掉viper.WatchConfig()和viper.OnConfigChange - 用
viper.ReadInConfig()读取一次即可，后续只读环境变量覆盖（viper.SetEnvKeyReplacer(strings.NewReplacer(".", "_"))有助于映射嵌套键名） - 注意
viper默认会搜索当前目录下多种格式配置文件（config.json,config.yaml等），生产镜像里不该存在这些文件，否则可能意外加载错误配置
如何用 build tags 隔离生产专用初始化逻辑
有些初始化操作只该在生产环境运行，比如连接 Sentry、启用 pprof 认证、设置 trace sampler 率。用 if env == "prod" 判断容易漏改、难测试，也增加运行时分支判断开销。
更可靠的方式是用 Go 的构建标签（build tags）做编译期隔离：
- 新建
init_prod.go，顶部加//go:build prod // +build prod
- 里面放生产专属逻辑：
sentry.Init(...)、pprof.RegisterAuth(...)，其他环境编译时直接剔除 - 构建时显式指定：
go build -tags prod -o myapp ./cmd/myapp - CI/CD 流水线中，dev/staging 构建不加
-tags，prod 构建强制加，从源头杜绝误用
HTTP server 启动前必须校验的三项生产约束
Go 的 http.ListenAndServe 一旦启动就阻塞，如果监听地址已被占用、TLS 证书路径错误、或健康检查端点没注册，服务看似“启动成功”，实则无法响应请求——这种失败非常隐蔽。
- 监听地址可用性：用
net.Listen("tcp", addr)尝试绑定再Close()，失败立即报错退出 - TLS 配置完整性：检查
tls.Certificate中的Certificates长度是否 > 0，且GetCertificate或GetConfigForClient函数已正确设置（尤其用 Let’s Encrypt ACME 时） - 健康检查端点就位：确保
/healthz或/readyz已注册，并在启动前调用一次 handler 模拟请求，验证返回码和 body 是否符合预期
这些检查都得放在 http.Serve() 之前，而不是丢进 goroutine 异步做——异步失败无法中止主流程，只会让服务带病上线。
