Go 程序启动时读不到 .env 文件？
Go 本身不自动加载 .env 文件，os.Getenv 只读系统环境变量，不会解析当前目录下的文件。常见错误是直接写 os.Getenv("DB_URL") 却忘了提前用第三方库（如 godotenv）把文件内容注入进程环境。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 必须在
main()最开头调用godotenv.Load()，否则后续任何os.Getenv调用都看不到变量 - 如果项目有多个环境文件（如
.env.development），需显式传参：godotenv.Load(".env.development") - 注意
godotenv.Load()默认只读当前工作目录下的文件，不是源码目录；CI/CD 中容易因执行路径不同而失败 - 避免在
init()函数里加载——Go 的包初始化顺序不可控，可能早于main执行，也可能被其他包触发多次
如何让 Go Web 服务按环境自动选配置？
靠硬编码判断 ENV=production 不可靠，容易漏改、难测试。真正稳定的方案是把环境决策点收口到配置加载阶段，而不是分散在业务逻辑里。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 定义统一配置结构体，字段用指针或零值可区分是否已设置（比如
*string或struct{ Host string `env:"HOST"` }） - 用
os.Getenv("ENV")决定加载哪个.env.*文件，但不要用它做业务分支（例如“if ENV == dev { log.SetLevel(Debug) }”） - 把环境相关参数（如日志级别、数据库连接池大小）也写进对应
.env文件，保持配置集中 - 别在 HTTP handler 里反复调用
os.Getenv——启动时一次性读取并缓存到全局配置变量中，减少系统调用开销
os.Setenv 在测试中改环境变量为什么无效？
因为 os.Setenv 只影响当前 goroutine 的环境副本，且无法覆盖已由 godotenv.Load() 加载过的变量（后者会跳过已存在的 key）。更关键的是：并发测试中多个 test case 共享进程环境，互相污染。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 单元测试中禁用
godotenv.Load()，改用godotenv.Overload()或手动os.Clearenv()+os.Setenv()组合 - 每个测试用例结束后调用
os.Unsetenv()清理，或者用testify/suite的SetupTest/TeardownTest统一管理 - 生产代码里永远不要依赖
os.Setenv动态切换配置——它不线程安全，且对子进程无影响 - 如果必须模拟多环境测试，推荐用接口抽象配置源（如
ConfigReader），测试时注入 mock 实现，而非动真实环境变量
部署时环境变量被 Docker/K8s 覆盖怎么办？
Docker 的 -e、K8s 的 envFrom 会直接写入容器环境，优先级高于本地 .env 文件。这时候 godotenv.Load() 仍会执行，但只填充空缺字段，容易造成“部分配置来自文件、部分来自平台”的混乱状态。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 上线前统一约定：生产环境禁止使用
.env文件，所有变量必须通过平台注入；开发/测试才启用godotenv - 在加载逻辑里加检查：
if os.Getenv("ENV") == "production" && len(os.Getenv("DB_HOST")) == 0 { log.Fatal("missing DB_HOST in production") } - 用
godotenv.Load()的返回错误判断文件是否存在，而不是静默忽略——缺失.env在开发机上应报错，避免误用默认值 - K8s ConfigMap 挂载为 env 文件时，路径不是
.env，而是类似/etc/config/.env，需显式指定完整路径
环境变量的加载时机和作用域比看起来复杂得多，尤其在跨平台部署时，一个没注意的加载顺序或路径偏差，就可能导致配置错位，而且问题往往延迟到运行时才暴露。
