os.Getenv读不到变量是因为进程只继承启动时的环境快照，需确认变量已生效；其返回空字符串无法区分“未设置”和“值为空”，应改用os.LookupEnv判断存在性。
os.Getenv 读不到变量？先确认它真在进程环境里
Go 程序启动时会拷贝父进程的环境变量快照，之后 os.Getenv 只能查这个快照，改系统级配置（比如 /etc/environment）或终端配置文件（~/.zshrc）后不重启 shell 就运行程序，大概率读不到。不是 Go 的问题，是环境没生效。
- Linux/macOS 下，在运行 Go 程序前，用
echo $YOUR_VAR在同一终端验证变量是否存在 - 如果用 IDE（如 Goland）运行，注意它可能不加载你的 shell 配置，得手动在 Run Configuration 里加 Environment Variables
- Docker 容器中，确保变量通过
-e或environment:显式传入，ENV指令只影响构建阶段，不自动透传给运行时 Go 进程
os.Getenv 返回空字符串 ≠ 变量未设置
os.Getenv 对不存在的键和值为空的键都返回空字符串 ""，无法区分“没设”和“设了但值为空”。这是最常踩的逻辑坑。
- 正确判断方式：用
os.LookupEnv，它返回value string, ok bool，ok为true才代表变量存在（哪怕值为空） - 别写
if os.Getenv("PORT") == ""就 fallback，默认端口——万一运维显式设了PORT=""，程序就崩了 - 示例：
port, exists := os.LookupEnv("PORT"); if !exists { port = "8080" }
敏感变量别硬编码默认值，用 panic 或 log.Fatal 提前暴露缺失
数据库地址、API 密钥这类必填环境变量，如果缺失却静默 fallback 到本地地址或测试密钥，上线后故障难定位。
- 对关键变量，建议直接检查
os.LookupEnv的ok，不满足就log.Fatal("missing required env: DATABASE_URL") - 避免在业务逻辑里反复调用
os.Getenv——每次都是 map 查找，性能差且易漏检；启动时集中读取、校验、存到全局 config struct 更可靠 - 注意：Windows 环境变量名不区分大小写，Linux/macOS 区分，
os.Getenv("Path")在 Windows 可能意外命中PATH，但别依赖这个行为
需要实时感知环境变化？os.Getenv 不行，得换方案
os.Getenv 是纯读取快照，进程运行期间即使外部改了 export FOO=bar，Go 里再调也还是旧值。真有动态重载需求，不能靠它。
立即学习“go语言免费学习笔记（深入）”；
- 常见做法：把配置项放到文件（如
.env）或远程配置中心（Consul、etcd），用 fsnotify 监听文件变化，或定期轮询 API - 某些场景可用
syscall.Getenv（仅 Linux），但它绕过 Go 运行时缓存，仍无法跨进程同步，且不跨平台，不推荐 - 更稳妥的是接受“环境变量即启动时契约”，动态配置走专用机制，别混用
环境变量看着简单，但 os.Getenv 的语义模糊性、进程隔离性、平台差异性，很容易在部署时才暴露问题。尤其是 os.LookupEnv 和 os.Getenv 的行为差别，几乎每个 Go 新手都掉过坑。
