go本身不自动读取.env文件，os.getenv仅查询进程启动时继承的系统环境变量；必须在main()开头显式调用godotenv.load()加载并注入，否则db_url等变量始终为空。
Go 本身不读 .env 文件，os.Getenv 只查操作系统环境变量——这是绝大多数人启动失败的第一原因。
为什么 os.Getenv("DB_URL") 总是空？
因为 Go 启动时不会自动解析项目根目录下的 .env 文件。你写 os.Getenv("DB_URL")，它只看系统进程环境，不是文件内容。
- 常见错误：直接运行
go run main.go，没加载.env，所有变量都为空 - 正确做法：必须在
main()最开头调用godotenv.Load()（或viper.AutomaticEnv()） - 路径陷阱：
godotenv.Load()默认读当前工作目录（pwd），不是main.go所在目录；CI/CD 中常因cd切换路径而失效 - 别在
init()里加载——包初始化顺序不可控，可能早于main()或被其他包触发多次
godotenv.Load() 多环境文件怎么选？
开发、测试、生产用不同 .env 文件时，不能靠硬编码判断 ENV=prod 再手动选，容易漏改、难测试。
- 推荐方式：用
os.Getenv("ENV")决定加载哪个文件，例如godotenv.Load(".env." + env) - 必须先读
ENV：比如env := os.Getenv("ENV"); if env == "" { env = "development" }，再传给Load() - 文件名要一致：约定好
.env.development、.env.production，避免拼写差异导致静默失败 - 注意覆盖逻辑：
godotenv.Load()不会覆盖已存在的环境变量，所以export DB_URL=xxx && go run main.go优先级高于文件
os.LookupEnv 比 os.Getenv 更安全在哪？
os.Getenv 返回空字符串无法区分“变量不存在”和“变量值为空”，os.LookupEnv 显式返回存在性标志，避免误判。
- 典型误用：
if os.Getenv("LOG_LEVEL") == ""→ 实际可能是LOG_LEVEL=""，而非未设置 - 正确写法：
if level, ok := os.LookupEnv("LOG_LEVEL"); ok { ... } - 配置校验场景尤其重要：比如
DB_URL必填，用LookupEnv能明确报错“missing DB_URL”，而不是连空串都接受 - 性能无差异，但语义更清晰，建议所有关键配置都用它
单元测试里改环境变量为什么总失效？
因为 os.Setenv 只影响当前 goroutine 的副本，且 godotenv.Load() 加载过的变量不会被覆盖；更麻烦的是多个 test case 共享进程环境，互相污染。
- 测试前清理：
os.Clearenv()+ 手动os.Setenv设置所需变量 - 或者用
godotenv.Overload()替代Load()，它会强制重载并覆盖已有变量 - 每个测试后务必
os.Unsetenv清理，或用testify/suite的SetupTest/TeardownTest统一管理 - 绝对不要在测试中依赖全局
init()阶段加载的.env—— 它在测试开始前就固定了
真正容易被忽略的点：环境变量不是“配置源头”，而是“最终汇入点”。无论用 viper 还是 godotenv，都要确保所有配置（包括日志级别、连接池大小、超时时间）都从同一入口加载并缓存，而不是在 handler 里反复调用 os.Getenv —— 系统调用开销小，但语义混乱、难以 mock、并发下可能读到中间态。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
