os.getenv 总返回空字符串是因为它不区分“未设置”和“值为空”，这是 go 的显式设计；应改用 os.lookupenv(value, ok) 通过布尔值判断变量是否存在，并手动校验空值、大小写、类型转换等。
os.Getenv 为什么总返回空字符串？
它不区分“变量没设”和“变量值为空”，两者都返回 ""。这不是 bug，是 Go 的显式设计：你得自己判断结果是否可信。
常见错误现象：os.Getenv("DB_PORT") 返回 ""，接着 strconv.Atoi("") 直接 panic；os.Getenv("API_URL") 拼出 https:// 然后请求失败。
- 验证变量是否真存在：终端执行
echo $DB_PORT（Linux/macOS）或echo %DB_PORT%（Windows），有输出才算设了 - IDE（如 GoLand）默认不加载 shell 环境变量，Docker 忘加
-e DB_PORT=5432就读不到 - 大小写敏感：Linux/macOS 下
os.Getenv("path")一定为空，必须用"PATH" - 别在
init()函数里读——包初始化顺序不可控，可能早于环境注入
os.LookupEnv 才是启动校验的标准姿势
os.LookupEnv 返回 value string, ok bool，第二个布尔值明确告诉你变量是否存在。这才是判断“配置是否到位”的唯一可靠方式。
典型用法：if dbUrl, ok := os.LookupEnv("DATABASE_URL"); !ok { log.Fatal("missing required env: DATABASE_URL") }
-
os.LookupEnv("HOME")→"/home/user", true -
os.LookupEnv("MISSING")→"", false - 值为空仍算“存在”：
os.Setenv("PORT", "")后调os.LookupEnv("PORT")返回"", true，你要自己strings.TrimSpace(value) == ""判断是否有效 - 性能无差异：底层共享同一张 map，多一次 bool 赋值可忽略
测试时读不到环境变量？不是 Go 的问题
go test 默认不继承父 shell 的完整环境变量，尤其在 IDE 或 CI 中更明显。本地 go run 正常，测试却崩，大概率是这个原因。
- 测试中显式设置：
os.Setenv("API_KEY", "test-key")，并用defer os.Unsetenv("API_KEY")清理 - 别依赖
.env文件自动加载：第三方包如godotenv是额外逻辑，上线时不会生效；测试应模拟真实部署场景 - 避免在测试函数外全局
os.Setenv—— 并发测试间可能污染
os.Environ 和 .env 文件的坑怎么绕开？
os.Environ() 返回 []string，每个元素形如 "KEY=VALUE"，但 VALUE 本身可能含等号（比如 URL=https://a=b/c），不能简单 strings.Split(e, "=")。
- 安全拆分写法：用
strings.IndexByte(kv, '=')找第一个等号位置，再切分 -
godotenv.Load()必须在main()最开头调用，否则数据库连接池等已初始化的包读不到新变量 - 它默认不覆盖已存在的环境变量，需加
godotenv.Overload()或godotenv.LoadWithOptions(godotenv.WithReplace()) - 所有值都是字符串，
PORT=3000不会自动转成 int，要自己strconv.Atoi(os.Getenv("PORT"))
os.LookupEnv，你也得自己处理 trim 空格、大小写归一、URL 解码、整数边界检查这些事。这些细节，往往比读取本身更消耗调试时间。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
