Go项目中敏感变量必须与配置文件分离，仅通过环境变量或Secret存储读取，严禁写入YAML/JSON；开发、测试、生产环境需各走独立安全通道，并在运行时校验关键字段非空。
Go 项目里敏感变量（如数据库密码、API密钥）不能硬编码，也不能靠 .env 文件直接提交进 Git——但光靠 viper.AutomaticEnv() 也不够。真正“优雅”的管理，是让敏感信息在开发、测试、生产三套环境里各走各的通道，且不破坏本地调试体验。
敏感变量必须和配置文件分离，不能写进 config.yaml
很多人把 db.password: "my-secret" 放进 config.dev.yaml，再用 viper.ReadInConfig() 加载，结果一不小心就把密钥推上 GitHub。这不是疏忽，是加载逻辑没设对。
- 所有敏感字段（
password、secret_key、private_key等）必须从环境变量或 Secret 存储中读取，**绝不允许出现在任何 YAML/JSON 配置文件中** -
viper.SetConfigFile("config.yaml")前，先调用viper.SetConfigType("yaml")，再显式禁用自动加载：viper.AutomaticEnv()要放在viper.ReadInConfig()之后，否则它会提前覆盖掉你手动设置的默认值 - 用
viper.SetEnvPrefix("APP")+viper.SetEnvKeyReplacer(strings.NewReplacer(".", "_"))把结构体字段database.password映射成环境变量APP_DATABASE_PASSWORD，避免手写映射逻辑出错
CI/CD 中必须用 env_file 加载密钥，而不是 shell 环境变量
本地 export APP_DATABASE_PASSWORD=xxx 可以跑通，但 CI 流水线里这么干等于裸奔：密钥会出现在构建日志、进程列表甚至缓存镜像里。
- Docker Compose 启动时，用
env_file: .env.prod指定密钥文件，并确保该文件被.gitignore排除；CI 中通过 secrets 注入，再用env_file挂载到容器内 - GitHub Actions 示例：
env_file不支持直接引用 secrets，得先写入临时文件：echo "APP_DATABASE_PASSWORD=${{ secrets.DB_PASS }}" >> $GITHUB_ENV，再让 Go 进程通过os.Getenv读取 - Kubernetes 场景下，用
Secret挂载为环境变量或卷，Viper 默认能读到，但要注意：挂载为文件时路径需显式添加viper.AddConfigPath("/etc/secrets")，且SetConfigName要匹配文件名
本地开发要用 asdf + .tool-versions 隔离 Go 版本，同时避免 .env 泄露风险
很多人在根目录放 .env 给本地调试用，结果 IDE 自动加载、Git 提交漏忽略、同事 clone 后直接执行——敏感信息就暴露了。
立即学习“go语言免费学习笔记（深入）”；
- 开发机上统一用
.tool-versions控制 Go 版本（如golang 1.22.5），配合 asdf 插件自动切换；这比改GOROOT或混用gvm更可靠 - 本地密钥不放
.env，改用viper.ReadRemoteConfig()模拟远程配置中心（如 etcd 本地实例），或用env_file: ./dev-secrets.env并加进.gitignore，且该文件模板（dev-secrets.env.example）只留占位符 - 启动命令加防护：比如
go run main.go --env dev，代码里检查viper.GetString("env") == "dev"时才允许读本地密钥文件，生产环境强制跳过
最易被忽略的一点：Viper 的 Unmarshal 不会校验结构体字段是否被环境变量实际填充。如果 APP_DATABASE_PASSWORD 没设，viper.Unmarshal(&cfg) 仍会成功，但 cfg.Database.Password 是空字符串——这会导致连接失败却无明确报错。上线前务必加运行时校验：if cfg.Database.Password == "" { log.Fatal("missing APP_DATABASE_PASSWORD") }。
