os.Getenv读不到环境变量的主因是变量未传入进程：shell配置未重载、IDE绕过shell、Docker未-e/ENV、大小写错误；os.Setenv仅当前进程有效；应优先用os.LookupEnv判空并设默认值，校验必要变量，注意PATH分隔符跨平台差异。
os.Getenv 读不到环境变量的常见原因
不是函数有问题，而是环境变量根本没传进进程里。Go 程序启动时只继承父 shell 的环境快照，改了 .bashrc 或 .zshrc 后没重新加载 shell，或者用 IDE 直接点运行（绕过 shell），os.Getenv 就会返回空字符串。
- 检查变量是否真存在：
echo $YOUR_VAR在终端里执行，确认有输出 - IDE 用户：在 Run Configuration 里手动添加环境变量，别依赖 shell 配置
- Docker 场景：确保
docker run -e YOUR_VAR=xxx或 Dockerfile 里用了ENV指令 - 注意大小写：
os.Getenv("PATH")可行，os.Getenv("path")在 Linux/macOS 返回空
os.Setenv 只影响当前进程，不写入系统
os.Setenv 是内存操作，调用后仅对当前 Go 进程及其后续 fork 出的子进程可见，不会修改 shell 的环境、不持久化、不影响其他正在运行的程序。
- 典型误用：想“永久设置”某个变量，结果程序退出就消失
- 子进程能继承：用
exec.Command启动新命令时，它会拿到当前进程的全部环境（含刚os.Setenv的值） - 线程安全：可并发调用，但多个 goroutine 同时
os.Setenv同一个键，结果取决于最后执行的那个 - 清空变量：设为空字符串
os.Setenv("FOO", "")不等于删除，os.Getenv("FOO")仍返回""；要真正“unset”，得用os.Unsetenv("FOO")
读取失败时别直接 panic，优先 fallback
生产环境里，os.Getenv 返回空是常态——变量可能缺失、拼错、或部署时被遗漏。硬 panic 会导致服务起不来，应该主动处理。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 用
os.LookupEnv替代os.Getenv：它返回(value string, ok bool)，能明确区分“值为空”和“变量未定义” - 提供默认值：比如
port := os.Getenv("PORT"); if port == "" { port = "8080" } - 关键配置建议集中校验：启动时遍历必要变量列表，统一报错并 exit，别等到 HTTP server listen 失败才暴露问题
- 注意类型转换：
os.Getenv总是返回string，转int或bool前务必用strconv.Atoi或strconv.ParseBool并检查 error
跨平台兼容性要注意 PATH 和分隔符
Windows 和 Unix-like 系统对环境变量的约定不同，硬编码路径拼接或分割逻辑容易出错。
-
os.Getenv("PATH")在 Windows 返回分号;分隔，在 Linux/macOS 是冒号:分隔——别自己strings.Split(..., ":") - 正确做法：用
filepath.SplitList(os.Getenv("PATH"))，它自动适配平台 - Windows 下变量名不区分大小写（
os.Getenv("Path")可能成功），但 Go 的os.Getenv严格按传入的字符串匹配，所以统一用大写习惯（如"PATH"）更稳妥 - 敏感变量（如密钥）避免打日志：即使
os.Getenv("API_KEY")被读取，也别把它直接塞进 error message 或 debug log
事情说清了就结束。环境变量看着简单，但部署时的继承链、IDE 的启动方式、跨平台分隔符、还有“空字符串”和“未定义”的语义差异，几个点叠在一起，很容易漏查。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
