应使用 os.lookupenv 替代 os.getenv，因其返回 (string, bool) 可明确区分变量是否存在；需手动校验空值、大小写、前后空格及换行符，生产环境应通过系统级环境变量注入而非 .env 文件。
别用 os.Getenv 直接取值上线，它返回空字符串时你根本不知道是“没设”还是“设了空串”，后续转 int 或拼 URL 会静默 panic。
为什么 os.Getenv 总返回空字符串
它不区分“变量未设置”和“变量值为空”，两者都返回 ""。这不是 bug，是设计：Go 要求你显式判断结果。
- 常见错误现象：
os.Getenv("DB_PORT")返回""，接着strconv.Atoi("")直接崩溃 - 验证方式：终端执行
echo $DB_PORT（Linux/macOS）或echo %DB_PORT%（Windows），有输出才说明真存在 - IDE 或 Docker 中常被忽略：Goland 默认不加载 shell 环境；Docker 忘加
-e DB_PORT=5432就读不到 - 大小写敏感：Linux/macOS 下
os.Getenv("path")一定为空，必须用"PATH"
用 os.LookupEnv 替代 os.Getenv
它返回 (string, bool)，第二个布尔值明确告诉你变量是否存在——这才是生产环境校验配置的标准姿势。
-
value, ok := os.LookupEnv("API_TIMEOUT")：若ok == false，说明变量压根没传进来，不是配置错，是部署漏了 - 关键变量建议直接
log.Fatal：if !ok { log.Fatal("missing required env: DATABASE_URL") } - 值为空仍算“存在”：
os.Setenv("PORT", "")后再调os.LookupEnv("PORT")→"", true，你要自己strings.TrimSpace(value) == ""判断是否有效 - 性能无差异：底层共享同一张 map，多一次 bool 赋值可忽略
测试时读不到环境变量？别依赖 shell
go test 进程默认不继承父 shell 的完整环境，尤其在 CI 或 IDE 里更明显。
- 正确做法：在测试函数里用
os.Setenv显式注入，defer os.Unsetenv清理 - 示例：
os.Setenv("JWT_SECRET", "test-secret"); defer os.Unsetenv("JWT_SECRET") - 避免在
init()里读环境变量：包初始化顺序不可控，可能早于环境注入 - 不推荐靠
.env文件自动加载测试：第三方库如godotenv是额外逻辑，上线时不会生效，测试应模拟真实部署场景
os.Environ 和 .env 文件的坑
os.Environ() 返回全部环境快照，但格式是 []string，每个元素形如 "KEY=VALUE"，而 VALUE 本身可能含等号。
- 拆分时必须用
strings.SplitN(s, "=", 2)，不能strings.Split(s, "=")，否则URL=https://a=b/c会被截断 -
godotenv.Load()只把文件内容“搬进”进程环境，不解析类型、不支持嵌套（如${HOST}），需手动启用WithExpand() -
.env必须在main()开头立即调用godotenv.Load()，放晚了（比如 HTTP server 启动后）变量就无效 - 生产环境别热重载
.env：每次Load()都要读文件+解析，应通过系统级环境变量注入
真正麻烦的不是怎么读，而是怎么让读到的字符串可信——它没有类型、没有 schema、没有 trim、不自动处理大小写。哪怕用了 os.LookupEnv，PORT 是 " 8080 " 还是 "8080\n"，还得你自己清。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
