Go运行时需手动通过环境变量（如APP_ENV=prod）或命令行参数指定配置，推荐用viper按config.{env}.yaml加载并分层合并，生产环境禁用.env文件而应使用环境变量或密钥管理服务。
go run 时怎么加载不同环境的配置文件
Go 本身不内置环境变量驱动的配置自动切换机制，go run 启动时不会自己读 .env 或按 GO_ENV=prod 挑配置文件。你得手动控制——要么靠命令行参数传入环境标识，要么靠环境变量在代码里分支判断。
常见错误是直接写 if os.Getenv("GO_ENV") == "prod" { load("config.prod.yaml") }，但忘了在 shell 中真正设这个变量：GO_ENV=prod go run main.go 才生效；漏掉 GO_ENV= 前缀或拼错名（比如写成 ENV），就会一直走默认分支。
- 推荐做法：统一用
os.Getenv("APP_ENV")，避免和 Go 自身的GOROOT/GOPATH等系统变量冲突 - 配置文件命名建议按
config.{env}.yaml规范，比如config.dev.yaml、config.staging.yaml - 别把敏感字段（如数据库密码）硬编码进 YAML，应通过环境变量覆盖：YAML 里写
password: "${DB_PASSWORD}"，再用godotenv或自定义解析器替换
使用 viper 时 dev/staging/prod 配置怎么分层合并
viper 支持多层级配置叠加，但默认行为容易误解：它不是“优先加载 config.prod.yaml → 覆盖 config.yaml”，而是“先读 config.yaml，再读 config.prod.yaml，后者字段会覆盖前者同名字段”。所以基础配置放 config.yaml，环境特有字段才单独拆出。
典型踩坑点：在 config.staging.yaml 里只写了 log_level: warn，但没写 db.host，结果运行时 db.host 是空——因为 viper 不会自动继承父配置，必须显式设置 viper.SetConfigName("config") 再 viper.MergeConfigMap 补全。
立即学习“go语言免费学习笔记（深入）”；
- 初始化顺序关键：先
viper.SetConfigFile("config.yaml")，再viper.SetConfigName(fmt.Sprintf("config.%s", env))，最后viper.ReadInConfig() - 若用目录方式（
viper.AddConfigPath("configs")），注意viper.WatchConfig()只监听最后加载的那个文件，不是整个目录 - 开发期建议禁用
viper.AutomaticEnv()，否则本地DB_URL环境变量会无声覆盖 YAML 里的值，排查困难
交叉编译部署到服务器时如何固化环境配置
静态二进制文件里不能带可变配置，go build 过程中也不能把 config.prod.yaml 打包进去。正确做法是：构建时不嵌入任何环境相关值，靠部署时注入——要么靠启动命令传参（./app -env=prod），要么靠容器挂载配置文件，要么靠远程配置中心拉取。
最容易被忽略的是：CI/CD 流水线里执行 CGO_ENABLED=0 GOOS=linux go build 时，如果代码里还调用了 os.Getenv("APP_ENV")，而构建机没设这个变量，viper 可能 fallback 到 dev 配置并悄悄编译进去——但上线后服务器没设该变量，就崩了。
- 构建阶段彻底剥离环境依赖：把所有
os.Getenv调用收口到一个GetEnv()函数，在测试中 mock，构建时用-ldflags "-X main.env=prod"注入编译期常量 - 生产镜像中不要 COPY 整个
configs/目录，只 COPY 当前环境所需文件，并设RUN chmod 600 /app/config.yaml防泄漏 - 如果用 Docker，别在
Dockerfile里写ENV APP_ENV=prod，而应在kubectl run或docker run -e APP_ENV=prod时传入，确保配置与镜像解耦
为什么线上环境不该用 .env 文件
.env 文件适合本地开发，但放到生产服务器上等于把密钥明文存硬盘。Kubernetes Secret、HashiCorp Vault 或云厂商的 Parameter Store 才是正解。更隐蔽的问题是：很多 Go 项目用 godotenv.Load(".env")，却没检查返回错误——如果文件不存在或权限不足，godotenv 默认静默失败，后续所有 os.Getenv 都返回空字符串，服务启动后连日志都打不出来。
另一个现实约束：容器重启后 .env 文件可能丢失（比如用 emptyDir），或者被运维误删。而环境变量注入是容器生命周期的一部分，稳定得多。
- 开发期可用
dotenv，但必须加错误处理：if err := godotenv.Load(); err != nil && !os.IsNotExist(err) { log.Fatal(err) } - 线上禁止
godotenv.Load()，改用viper.AutomaticEnv()+ 显式前缀（如viper.SetEnvPrefix("APP")），让APP_DB_URL映射到db.url - 如果非要用文件，选
/etc/secrets/app-config.json这类固定路径，由 infra 统一挂载，代码里硬编码路径反而比动态搜.env更可靠
