Go企业级脚手架中，编译期注入环境变量必须用-ldflags或embed，不能依赖os.Getenv运行时加载，否则破坏可重现性、绕过审计、泄露敏感值。
Go 本身不解析 .env 文件，os.Getenv 只查进程启动时继承的系统环境变量——你在 Docker 或 Kubernetes 里跑 Gin 应用，如果只靠 .env 文件却没显式加载，所有配置都会是空字符串。
为什么 os.Getenv("DB_URL") 在容器里总是空
不是代码写错了，是部署时根本没把变量传进去。Kubernetes 的 envFrom: configMapRef 或 Docker 的 -e DB_URL=xxx 没配，或者配了但 key 名拼错（比如写成 db_url 而不是 DB_URL），os.Getenv 就返回 ""，不会报错也不会提示。
-
os.Getenv无法区分“变量未设置”和“变量值为空”，上线后转int或拼URL会直接 panic - Docker Compose 中漏写
environment:或env_file:，或路径写错（如./.env.prod实际在deploy/目录下） - Kubernetes 中
configMapKeyRef的key不存在，该环境变量压根不会被注入，os.Getenv返回空串 - Gin 启动前没做校验，等到连接数据库时报
parse "": empty url才发现
os.LookupEnv 是生产环境读变量的唯一合理姿势
它返回 (string, bool)，第二个布尔值明确告诉你变量是否真实存在，而不是靠空字符串猜。
- 关键配置必须强制存在：
if dbURL, ok := os.LookupEnv("DATABASE_URL"); !ok { log.Fatal("missing required env: DATABASE_URL") } - 值为空仍算“存在”，得额外判断：
if strings.TrimSpace(dbURL) == "" { log.Fatal("DATABASE_URL is set but empty") } - 测试时用
os.Setenv注入，不用依赖 shell 环境：os.Setenv("JWT_SECRET", "test-secret"); defer os.Unsetenv("JWT_SECRET") - 别在
init()里调用，包初始化顺序不可控，可能早于环境注入
容器里要不要用 godotenv.Load()
不要。它只适合本地开发调试，上线时应完全禁用——Docker/K8s 都通过原生机制注入环境变量，godotenv 不仅多余，还可能掩盖部署配置缺失问题。
立即学习“go语言免费学习笔记（深入）”；
-
godotenv.Load()默认读当前工作目录（pwd），而容器启动路径常为/app，.env文件若放在项目根目录就找不到 - 它不会覆盖已存在的环境变量，所以
docker run -e DB_URL=prod...优先级高于文件，容易造成本地测试和线上行为不一致 - CI/CD 流水线中若用
go run main.go启动，godotenv可能因路径切换失效，但你根本察觉不到 - 真正需要多环境文件（如
.env.production）的场景，应该由部署平台控制，而不是代码里硬编码逻辑
Gin + Viper 的配置 fallback 链该怎么搭
别让 Viper 自动 fallback 到文件，生产环境只信环境变量；文件仅作本地开发兜底，且必须显式开关。
- 初始化时禁用自动加载：
viper.AutomaticEnv()是必须的，但去掉viper.ReadInConfig()或仅在ENV != "production"时调用 - 用
viper.SetEnvKeyReplacer(strings.NewReplacer(".", "_"))把server.port映射成SERVICE_PORT，避免大小写混乱 - 必填字段用
viper.IsSet("database.url")+os.LookupEnv双校验，防止 Viper 从空文件读出默认零值 - 挂载的 ConfigMap 文件（如
/config/app.yaml）要先os.Stat检查存在性，再viper.SetConfigFile，不能假设路径一定就绪
最易被忽略的一点：Kubernetes 中 env.valueFrom.secretKeyRef 如果 key 不存在，该变量根本不会出现在容器环境里，os.LookupEnv 的 ok 会是 false——但很多人只测了 ConfigMap，忘了 Secret 也要同步维护 key 名。
