os.Getenv读不到变量主因是进程未继承该环境变量，需确认其真实存在于启动时环境快照中；应优先用os.LookupEnv区分“未设置”与“值为空”，并注意跨平台大小写、IDE/Docker/K8s注入差异及动态重载局限。
os.Getenv 读不到变量？先确认它真在进程环境里
Go 进程只继承启动时的环境快照，os.Getenv 查不到，大概率不是函数问题，而是变量根本没传进来。Linux/macOS 下用 echo $YOUR_VAR 在同一终端验证；Windows 用 echo %YOUR_VAR%。IDE（如 VS Code、Goland）通常不自动加载 shell 配置，得手动在运行配置里加 Environment Variables。
Docker 容器中常见误判：ENV 指令只影响构建阶段，运行时必须用 -e VAR=value 或 environment: 显式注入；Kubernetes 中若用 envFrom.configMapKeyRef，ConfigMap 的 key 必须全大写、只含字母/数字/下划线，否则 Go 进程收不到。
- 别指望
os.Getenv能读到~/.bashrc里写的export—— 进程没重启，shell 配置不会自动生效 - 拼写和大小写必须完全一致：Linux 下
DB_URL和db_url是两个变量；Windows 虽不区分，但别依赖这个行为 - 本地
go run main.go正常，go test报空？因为测试进程默认不继承父 shell 环境，尤其 CI 或 IDE 内部执行时
os.Getenv 返回空字符串，不代表变量没设
os.Getenv 对“未设置”和“值为空”都返回 ""，这是最易引发静默 panic 的点。比如 strconv.Atoi(os.Getenv("PORT")) 遇到空串直接崩溃，却无法判断是漏配、拼错，还是运维真写了 PORT=。
真正该用的是 os.LookupEnv：它返回 value string, ok bool，ok == true 才代表变量真实存在（哪怕值是空字符串）。
立即学习“go语言免费学习笔记（深入）”；
- 必填变量缺失时，立刻
log.Fatal("missing required env: DATABASE_URL")，别等连接数据库时报错 - 带默认值逻辑要分两步：
if val, ok := os.LookupEnv("LOG_LEVEL"); !ok { val = "info" }，避免把空值误当默认值 - 布尔开关别写
os.Getenv("DEBUG") == "true"，改用strings.EqualFold(debug, "true")兼容大小写
os.Setenv 只影响当前进程，别想持久化或跨进程生效
os.Setenv 修改的是当前 Go 进程内存里的环境副本，调用后启动的子命令（如 exec.Command("sh", "-c", "echo $FOO")）能继承，但它不会写入 shell、系统注册表或父进程。进程退出，一切归零。
常见误用：
- 在 HTTP handler 里反复
os.Setenv，期望影响其他 goroutine —— 虽线程安全，但无业务意义，还可能干扰并发子命令 - 测试中只
os.Setenv不os.Unsetenv，污染后续测试；正确做法是先old, ok := os.LookupEnv("KEY")，测试完按需恢复 - 忽略错误返回：
os.Setenv在键含=或\x00时会返回 error，生产代码应检查
跨平台环境变量名大小写处理差异
Windows 下 PATH、Path、path 指同一个变量；Linux/macOS 下严格区分。这意味着：
os.Setenv("MyVar", "1") 后再调 os.Getenv("myvar")，Windows 可能返回 "1"，Linux 一定返回 ""。
- 统一使用全大写 + 下划线风格（如
DB_HOST、REDIS_PORT），避免混用大小写变体 - 别在代码里写
os.Getenv("Path")期望兼容 Windows —— 行为不可靠，且 Linux 上失效 - 子进程是否需要继承这些变量？不是所有场景都需要。显式构造
exec.Command时，可清空Cmd.Env再按需添加，比盲目继承更可控
os.Getenv。 
