应使用os.LookupEnv而非os.Getenv，因其返回(string, bool)可明确区分“值为空”和“变量未设置”，避免因误判空值导致后续panic；它底层性能无差异，且是启动时校验必要配置的标准方式。
别用 os.Getenv 直接取关键配置，它不报错、不区分“没设”和“设为空”，上线后 panic 很难定位。
为什么 os.Getenv 总返回空字符串？
它只做一件事：查键、返回字符串。查不到就返回 ""，不会告诉你变量压根不存在。你看到空串，可能是：
-
DB_PORT根本没在 shell 里export，或 Docker 忘加-e DB_PORT=5432 - 拼写错误，比如用了
db_port（小写）而系统里是DB_PORT - IDE 启动时绕过了 shell，没加载
.zshrc里的环境变量 - 变量确实被设成了空值：
export API_KEY=""
验证方法很简单：终端里执行 echo $DB_PORT，有输出才说明真存在。
什么时候必须用 os.LookupEnv？
它返回 (string, bool)，ok == false 才代表变量未设置——这是唯一能可靠判断“是否存在”的方式：
立即学习“go语言免费学习笔记（深入）”；
- 启动校验：if dbUrl, ok := os.LookupEnv("DATABASE_URL"); !ok { log.Fatal("missing required env: DATABASE_URL") }
- 默认值逻辑：if port, ok := os.LookupEnv("PORT"); !ok { port = "8080" }
- 布尔开关：if debug, ok := os.LookupEnv("DEBUG"); ok && strings.EqualFold(debug, "true") { /* enable debug */ }
os.LookupEnv 和 os.Getenv 读的是同一份进程启动时的环境快照，性能无差异，只是接口语义更严谨。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
os.Getenv 还能用吗？怎么用才不翻车？
能用，但仅限于两种场景：
- 你明确知道该变量一定存在，且空值本身有意义（比如允许
LOG_LEVEL=""表示不打日志） - 你手动补了非空判断：
if port := os.Getenv("PORT"); port != "" { /* use it */ }
但注意：os.Getenv("PATH") 在 Windows 返回分号分隔，在 Linux/macOS 是冒号分隔；转 int 或 bool 前必须用 strconv.Atoi / strconv.ParseBool 并检查 error；os.Environ() 返回的是启动时快照，顺序不保证，拆分时要用 strings.SplitN(s, "=", 2) 避免 VALUE 里含等号出错。
想自动加载 .env 文件怎么办？
Go 标准库不支持。必须引入第三方包，比如 github.com/joho/godotenv，并在 main() 开头立刻调用：
func main() {
godotenv.Load(".env") // 必须在任何 os.Getenv / os.LookupEnv 调用之前
// ...
}容易踩的坑：
- 忘记调用
Load()，或调得太晚（比如在 HTTP server 启动之后） - 误以为
godotenv.Load()会自动注入到系统环境——它只是把文件内容塞进进程环境，后续仍要用os.LookupEnv读 - 生产环境热重载
.env不安全，应通过系统级方式注入（Docker-e、K8senvFrom）
真正麻烦的不是读不到，而是读到了一个不可信的字符串——它没类型、没 schema、没大小写约定，所有校验和转换都得你手写，而且一漏就 panic。
