应先用 os.lookupenv 判断环境变量是否存在，再用 strings.trimspace 检查是否为空；关键配置缺失用 log.fatal，非关键项可设默认值并 warn。
启动时检测 os.Getenv 返回空值就 panic？别急，先确认是否真缺失
Go 启动阶段读环境变量出错，多数不是“读不到”，而是变量存在但值为空字符串（""）或只含空白符。比如 DB_URL= 在 shell 中合法，但 os.Getenv("DB_URL") 返回 " "，直接判空会误报。
- 用
strings.TrimSpace(os.Getenv("DB_URL")) == ""替代os.Getenv("DB_URL") == "" - 区分“未设置”和“设为空”：调用
os.LookupEnv("DB_URL")，它返回(string, bool)，第二个布尔值才是“是否存在”的权威答案 - 常见陷阱：Docker Compose 或 Kubernetes 的
env:块里写了- DB_URL（没赋值），实际注入的是空字符串，不是未定义
github.com/spf13/viper 自动 fallback 到默认值？小心覆盖真实缺失
Viper 默认开启 AutomaticEnv()，但它把环境变量名转成大写+下划线后匹配 key，比如 viper.GetString("db.url") 会查 DB_URL。问题在于：如果没设 DB_URL，viper 返回空字符串而非 nil，且不会告诉你“这个 env 根本没提供”。
- 启用
viper.SetConfigType("env")并手动调用viper.ReadInConfig()不适用——env 没有文件格式 - 正确做法：在
viper.AutomaticEnv()后，对每个关键键显式调用viper.IsSet("db.url")，它只返回 true 当该 key 被显式设置过（包括 env、flag、config file） - 更稳的组合：用
os.LookupEnv先校验变量是否存在，再交由 viper 处理值；避免依赖 viper 的“模糊匹配”逻辑
panic 还是 log.Fatal？取决于配置项是否可降级
不是所有缺失都该让服务直接退出。比如 LOG_LEVEL 缺失可以 fallback 到 "info" 并 warn；但 JWT_SECRET 缺失必须 panic——加密密钥不存在，后续所有鉴权都不可信。
- 硬依赖项（数据库连接串、密钥、API token）：用
log.Fatal("missing required env: JWT_SECRET")，不带堆栈，清晰表明启动失败原因 - 软依赖项（超时时间、重试次数）：用
log.Warnf("env RATE_LIMIT not set, using default 100")+ 显式赋默认值 - 避免
panic：它打印完整堆栈，掩盖真正问题（比如你其实只想说“JWT_SECRET 为空”，结果输出 50 行 goroutine 状态）
测试环境变量缺失场景，别只靠 go run 手动删 export
本地手动 unset DB_URL && go run main.go 很难覆盖所有边界：比如 CI 环境里变量被空字符串覆盖、Docker 构建时 ARG 覆盖 ENV、systemd service 文件里漏写 Environment=。
立即学习“go语言免费学习笔记（深入）”；
- 写一个最小验证函数：
func mustGetEnv(key string) string { if val, ok := os.LookupEnv(key); !ok { log.Fatal("required env not set:", key) } else if strings.TrimSpace(val) == "" { log.Fatal("required env is empty or whitespace:", key) } return val } - CI 测试时，在
before_script里故意 unset 关键变量，看是否 fail-fast - Dockerfile 中避免
ENV DB_URL=""，改用ARG DB_URL+ENV DB_URL=${DB_URL}，这样构建时不设 ARG 就真的没这个 env
最常被忽略的点：Kubernetes 的 valueFrom: configMapKeyRef 如果 key 不存在，容器启动时该 env 变量根本不会被注入——此时 os.LookupEnv 返回 false，但很多人只测了 os.Getenv 返回空字符串的情形。
