应使用 os.lookupenv 而非 os.getenv，因其返回 (value, ok) 可区分“未设置”与“设为空”；适用于启动校验、默认值逻辑、布尔开关处理；测试用 t.setenv，注意生效时机与作用域。
别用 os.Getenv 直接取值，尤其当变量是必填项或需区分“未设置”和“设为空”时——它静默返回空串，后续 panic 很难定位。
为什么 os.Getenv 容易导致线上静默失败
它只返回 string，不告诉你这个空串到底是“系统根本没设该变量”，还是“你手动设了 MY_VAR=（空值）”。比如：
-
os.Getenv("DATABASE_URL")返回""，可能是漏配、拼错名（DB_URL）、大小写错误（database_url），也可能是配置里真写了空值 - 若直接传给
sql.Open，会 panic 报 “invalid URL”，但日志里看不到是哪个环境变量出的问题 - 在 Docker 或 Kubernetes 里，
envFrom.configMapKeyRef若 key 不存在，变量压根不会被注入——os.Getenv依然只返回""，毫无提示
必须改用 os.LookupEnv 的三种场景
它返回 (value string, ok bool)，ok == false 才代表变量未设置，这才是判断“是否存在”的唯一可靠方式：
- 启动校验：必要变量缺失时立刻
log.Fatal("missing required env: ", key)，而不是等到连接数据库时报错 - 默认值逻辑：
if val, ok := os.LookupEnv("LOG_LEVEL"); !ok { val = "info" }，避免把空字符串误当默认值 - 布尔开关处理：
if debug, ok := os.LookupEnv("DEBUG"); ok && strings.EqualFold(debug, "true") { ... }，防止os.Getenv("DEBUG") == "true"在值为"TRUE"或"1"时失效
测试中模拟环境变量的正确姿势
Go 1.17+ 提供 t.Setenv，它是目前最安全的测试方案：
- 必须在
t.Parallel()之前调用，否则无效 - 它只作用于当前测试函数，结束后自动还原，不会污染其他测试
- 对
init()中读取的变量无效——因为init在测试函数运行前就执行完了，此时t.Setenv还没生效 - 别再手写
os.Setenv+defer os.Unsetenv：并发测试下可能漏恢复，panic 时 defer 不执行，后续测试全乱
容器与 IDE 环境里读不到变量？先确认它真进了进程
不是 Go 函数有问题，而是变量根本没传进去：
- Linux/macOS：终端里跑
echo $PORT，有输出才说明 shell 真导出了；go run main.go能读到，不代表go test也能——测试进程默认不继承全部环境 - Docker：必须显式
docker run -e PORT=8080，或Dockerfile里写ENV PORT=8080；仅写export PORT=8080在构建机上没用 - Kubernetes：ConfigMap 的 key 必须全大写、只含字母/数字/下划线，否则 Go 进程收不到；
env.valueFrom.configMapKeyRef.key拼错，变量就不会出现在容器环境里 - VS Code：默认不加载 shell 的
.zshrc，得在.vscode/settings.json里配"go.toolsEnvVars"，或改用集成终端启动
最容易被忽略的一点：环境变量是进程启动时的快照，os.Getenv 不会重读。把它当动态配置源，等于埋了个定时雷。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
