os.lookupenv 的 bool 返回值才是判断环境变量是否设置的关键：found为false表示未声明，true表示已声明（即使value为空）。
os.LookupEnv 返回的 bool 值才是关键判断依据
很多人误以为 os.Getenv 返回空字符串就代表环境变量未设置，其实它对未设置和设为空值（FOO=）都返回 ""。真正能区分两者的只有 os.LookupEnv —— 它返回两个值：value string 和 found bool。found 为 false 表示变量根本没在环境里声明；为 true 时，哪怕 value 是 ""，也说明变量存在且被显式设为空。
常见错误：把空字符串当成“未设置”来处理
比如这样写会出错：
if os.Getenv("DEBUG") == "" {
// 错！这里无法区分是没设 DEBUG，还是 DEBUG=""
}
正确做法是始终用 os.LookupEnv 并检查第二个返回值：
- 如果
found == false→ 环境变量未声明，可走默认逻辑或报错 - 如果
found == true && value == ""→ 变量存在但为空，通常需特殊处理（如禁用某功能） - 如果
found == true && value != ""→ 正常取值使用
实际使用中要注意 shell 赋值方式的影响
环境变量是否“被设置”，取决于启动进程时的环境快照，而 shell 中不同赋值方式结果不同：
-
unset FOO; go run main.go→os.LookupEnv("FOO")返回"", false -
FOO= go run main.go→os.LookupEnv("FOO")返回"", true -
FOO="" go run main.go→ 同样返回"", true -
FOO=1 go run main.go→ 返回"1", true
这意味着你在测试时不能只靠 echo $FOO 判断——shell 里 echo 对未设置和空值都输出空行，必须用 declare -p | grep FOO 或直接在 Go 里打印 os.LookupEnv 的两个返回值。
需要兼容旧代码时别偷偷替换为 Getenv
有些老项目里混用了 os.Getenv 和 os.LookupEnv，一旦把某个 Getenv 改成 LookupEnv 却只取第一个返回值（忽略 found），逻辑就变了。例如：
// 旧逻辑：未设置时返回 ""，调用方用 len()==0 判断
v := os.Getenv("PATH")
// 新逻辑（错误）：只取 value，丢了 found，行为不等价
v, _ := os.LookupEnv("PATH") // 不要这样丢掉 bool！
真要迁移，必须同步改调用方逻辑，明确处理 found 分支。否则线上可能把“未设置”误判成“设为空”，导致配置失效或 panic。
最易被忽略的是 CI/CD 环境和容器启动脚本里那些看似无害的 ENV VAR= 指令——它们会让 found 变成 true，但值为空，如果你的代码只检查空字符串就跳过，那其实已经悄悄启用了空配置。
