最稳妥做法是封装 env() 函数统一读取并归一化 go_env：先 os.getenv("go_env")，为空则 fallback "development"，再 strings.tolower；敏感字段为空直接报错退出，禁用 viper.automaticenv()，测试通过 testmain 显式设 env。
直接用 os.Getenv("GO_ENV") 读取并设默认值是最稳妥的起点，但不校验空值、不统一前缀、不在初始化阶段集中处理，迟早会在线上跑出 panic: runtime error: invalid memory address 或静默连错数据库。
怎么安全读取 GO_ENV 并 fallback
环境变量未设置时 os.Getenv 返回空字符串，不是 nil，直接比较 == "production" 会走错分支。必须立刻兜底：
-
env := os.Getenv("GO_ENV")后立即判断：if env == "" { env = "development" } - 建议归一化大小写：
strings.ToLower(env)，避免"Dev"和"DEV"被当成不同环境 - 不要在多个包里重复写这套逻辑，封装成
Env()函数，全局只有一处判断入口
配置结构体必须按环境动态填充，别拆文件
写 config_dev.go 和 config_prod.go 看似清晰，实则导致字段重复、合并冲突、测试难覆盖。正确做法是定义一个统一 Config 结构体，在初始化时根据 GO_ENV 填充字段：
- 数据库地址：
if env == "production" { cfg.DBURL = os.Getenv("DATABASE_URL") } else { cfg.DBURL = "localhost:5432" } - 日志级别：
cfg.LogLevel = map[string]string{"development": "debug", "production": "info"}[env] - 敏感字段（如密钥）绝不设默认值，
os.Getenv("API_KEY")为空就报错退出，不 fallback
viper 绑定环境变量的坑：AutomaticEnv() 是毒药
很多人启用 viper.AutomaticEnv() 后发现 HOME、PWD 全被当配置覆盖了——它无差别映射所有环境变量，根本不管业务前缀。必须关掉：
- 调用
viper.SetEnvPrefix("APP")，再逐个绑定：viper.BindEnv("server.port", "PORT") - 避免用
viper.SetConfigName("config." + env)拼接文件名，Docker 镜像里没那么多 YAML 文件可读 - 如果只靠环境变量启动，别引入 viper；它带来的复杂度远超收益，裸用
os.Getenv+ 结构体更可控
测试时环境变量不能靠 shell 透传
APP_ENV=test go test ./... 在本地可能有效，但在 CI/CD 或 Docker 中完全失效——go test 子进程不继承父 shell 环境。可靠方案只有两个：
- 在
TestMain里显式os.Setenv("GO_ENV", "test")，用defer os.Unsetenv("GO_ENV")清理 - 禁用所有
init()函数里的配置加载，否则测试无法重置状态；把初始化逻辑收进NewConfig()函数里 - 测试用例中不要连真实 DB 或发 HTTP 请求，把外部依赖抽象为接口，测试时注入 mock 实现
最常被忽略的是：环境变量名必须参与配置加载路径决策。比如生产环境用 GO_ENV=staging 启动，但代码里只认 "production"，结果它悄悄读了开发配置连测试库——这种错误不会报错，只会半夜炸掉监控。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
