Go 项目中如何管理敏感配置信息（如 API Key）？

直接暴露在代码或环境变量里，API key的安全防线其实就已经开始失守了。真正安全的做法是：不让敏感值以明文形式出现在进程内存以外的任何地方——包括 shell 历史、ps 输出、日志、配置文件，乃至 git 提交记录。 ### os.LookupEnv + 显式校验必须写在启动入口 用 `os.Getenv` 读取敏感字段是个危险的起点——它对缺失、空值、空白符全无提示，容易让服务带着空密钥静默启动。正确做法是在 `main()` 或 `init()` 里强制校验： - 用 `os.LookupEnv` 获取 `(string, bool)` 二元结果，明确区分“未设置”和“设为空字符串”； - 对每个必填敏感字段（比如 `API_KEY`、`DB_PASSWORD`）做双重判断：`!ok` 或 `len(value) == 0`； - 校验失败立即 `log.Fatal`，不 fallback 到测试密钥——测试密钥也应带 `test-` 前缀，并仅限本地构建标签启用。 ### 敏感字段绝不进日志、JSON、HTTP 响应体 哪怕只是在调试时写一行 `fmt.Printf("%+v", cfg)` 或 `log.Println(cfg)`，都可能把密钥打到 stdout、Sentry、ELK 里。结构体定义必须做好主动防御： - 对敏感字段加 `json:"-" yaml:"-"` 标签，阻止自动序列化； - 实现 `String()` 方法，返回脱敏形式，比如 `Password: ***`； - HTTP handler 中禁止传整个配置 struct 给 `slog.With`，得手动提取非敏感字段构造键值对； - 绝不在响应中返回 `os.Environ()` 或任意 `os.Getenv` 结果。 ### 避免 .env 文件提交风险，但可用 godotenv 限域加载 可别误会，`.env` 文件本身不是原罪，罪在它被误提交、误同步、误用于 CI。安全用法有明确的边界： - 只在 `cmd/` 包的 `main.go` 开头调用 `godotenv.Load()`，绝不放在 `internal/` 或 `pkg/`； - `.env` 必须进 `.gitignore`，同时配套提供 `.env.example`（只含变量名和注释，无值）； - CI 环境禁用 `.env`——GitHub Actions 用 `secrets`，Kubernetes 用 `Secret` 挂载，Docker Compose 用 `environment` + `env_file` 分离； - 本地开发若需快速启动，可配合 `go:build dev` 标签，让 `godotenv` 只在 dev 构建中生效。 ### 文件加载比环境变量更可控，但路径本身要保密 把密钥存在文件里（比如 `./secrets/api.key`），再通过环境变量指向路径，能规避 shell 历史和 `ps aux` 泄露，但前提是路径不能暴露： - 使用 `gh_mirrors/en/env` 的 `file` 标签：`APIKey string \`env:"API_KEY,file"\``； - 环境变量只存路径，如 `export API_KEY="./secrets/api.key"`，该路径本身不能含密钥信息（避免 `API_KEY_PROD_2026.key` 这类命名）； - 文件权限设为 `600`，且所在目录不可被 Web 服务器或静态文件服务访问到； - 注意：文件加载仍会把内容读入进程内存，所以后续仍需遵守脱敏打印、不透出等规则。 最常被忽略的一点：敏感配置的安全性，不取决于你用了多强的加密算法，而取决于它从加载进内存那一刻起，是否被任何非必要代码路径触达过——包括反射、通用日志、panic 堆栈、pprof profile 输出。越早切断传播链，越接近真正安全。