不能只用os.Getenv读环境变量，因其仅返回字符串且缺失时返回空串，缺乏类型转换、默认值兜底、必填校验及结构体映射能力，易导致运行时panic、配置遗漏或解析错误。
os.Getenv 不能直接替代配置管理，它只是底层访问接口；真正可靠的环境变量加载必须配合类型转换、默认值兜底、错误校验和明确的优先级控制。
为什么不能只用 os.Getenv 读环境变量
很多人在项目初期直接用 os.Getenv("PORT")，结果上线后遇到端口没设就启动失败、数据库密码为空连不上、布尔字段解析成空字符串等故障。根本原因是：os.Getenv 返回 string，且缺失时返回空串，不做任何类型或有效性检查。
- 类型不安全：你得手动调
strconv.Atoi、strconv.ParseBool，漏掉错误检查就会 panic - 无默认值机制：每次都要写
if port == "" { port = "8080" }，重复又易错 - 无法标记必填项：生产环境漏配
DB_DSN_URL，程序跑起来才报错，而不是启动时立刻失败 - 不支持嵌套结构：比如
LOG_LEVEL和LOG_ROLLBAR_ENV是同一组配置，但os.Getenv没法自动聚合成LogConfig结构体
cleanenv 加载 YAML + 环境变量的正确姿势
go-coffeeshop 项目用 github.com/ilyakaznacheev/cleanenv 的核心优势不是“多一种格式”，而是把环境变量和 YAML 统一到结构体映射层，并强制类型和必填校验。关键点在于字段 tag 的写法和加载顺序。
- 环境变量优先级必须高于 YAML：这是 cleanenv 默认行为，但前提是字段同时声明
env和yamltag，例如DsnURL string `env:"PG_DSN_URL" yaml:"dsn_url"` - 必填项用
env-required:"true"，不是required或其他写法，否则 cleanenv 不识别 - YAML 文件路径要显式传入：
cleanenv.ReadEnv(&cfg, os.Args[1:]...)不会自动找config.yml，得先os.ReadFile("cmd/barista/config.yml")再调cleanenv.ReadConfig - 结构体字段必须导出（首字母大写），否则 cleanenv 无法反射赋值
本地开发用 godotenv 但别让它污染测试
godotenv.Load() 很方便，但它在 init 阶段调用会污染整个进程的环境变量空间，导致单元测试读到不该读的值，或者并发 init 时出现 race。
- 不要在
main()里调用godotenv.Load()—— 这会让所有包都看到 .env 变量，包括测试包 - 测试时应独立加载：
func init() { godotenv.Load(".env.test") }，并用go test -tags test控制执行时机 - 永远检查错误：
if err := godotenv.Load(); err != nil && !os.IsNotExist(err) { log.Fatal(err) }，否则 .env 文件权限不对或编码异常时静默失败 - CI/CD 中禁用
godotenv：Kubernetes ConfigMap 或 Secret 注入的环境变量已就位，再加载 .env 反而覆盖真实值
环境变量和 ConfigMap 字段对齐的坑
Kubernetes 里 ConfigMap 挂载为环境变量时，Go 代码不能靠“猜”去读，字段名必须严格一致。尤其注意大小写、分隔符和嵌套展开规则。
立即学习“go语言免费学习笔记（深入）”；
- ConfigMap 中写
db_host: localhost，Go 里就得用os.Getenv("DB_HOST")，不是DBHOST或db.host - 如果 ConfigMap 是挂载为文件（如
/etc/config/app.yaml），就别用os.Getenv，改用gopkg.in/yaml.v3解析，且 struct tag 必须是yaml:"db_host"，不是json:"db_host" - 布尔值别加引号：
debug: true✅，debug: "true"❌ —— 后者解析出来是 string，不是 bool - 避免混用来源：同一个配置项（如
APP_LOG_LEVEL）既从环境变量读、又从 YAML 读，cleanenv 能合并，但viper或手写逻辑容易覆盖错位
os.Getenv，也该封装一层带类型转换和 fallback 的 helper；若用库，就要吃透它的 tag 规则和加载顺序——否则配置系统反而成了故障放大器。 
