12-Factor 配置原则
出处是 12-Factor App 的第 III 条 Config 与第 X 条 Dev/Prod Parity：配置与代码严格分离，环境相关的一切（连接串、凭据、外部地址）都从环境注入，代码在任意环境按同一方式运行。判断标准很直接：代码可以开源而不泄露任何凭据，配置全部在环境里。反面模式是把开发与生产的差异写成代码里的常量或分支，环境一变就要改代码重新构建。配置指随部署环境变化的部分；不因环境变化的分级参数（如路由表）属于代码。
基本信息
| 出处 | 12-Factor App 第 III 条 Config、第 X 条 Dev/Prod Parity |
|---|---|
| 反面模式 | 把开发与生产差异写成代码里的常量或分支 |
| 判断标准 | 代码可开源而不泄露凭据，配置全在环境里 |
| 边界 | 随环境变化的是配置，不随环境变化的是代码 |
| 落地载体 | 环境变量、配置中心、挂载的配置文件 |
典型使用场景
- 容器化应用：镜像一份，环境差异全部靠注入，镜像在任意环境运行。
- 多环境部署：开发、预发、生产用同一制品加不同配置。
- 开源项目：仓库可公开，凭据不进入代码。
- 安全合规：凭据不落代码与镜像，缩小泄露面。
- 灾难恢复：重建环境只需要制品加配置，不需要改代码。
- 配置审计：配置来源集中（配置中心或密钥管理），变更可追踪。
正反示例
正反示例
# 反例：代码里按环境分支取地址
# if env == 'prod': db = '10.0.0.5' else: db = '127.0.0.1'
# 正例：统一从环境注入
export DATABASE_URL=postgres://user:pass@host:5432/app
# 启动方式一致，不同环境只换注入值
./deploy.sh判断配置的边界：只有随部署环境变化的部分才是配置；稳定的业务参数留在代码里，两边都要有清晰归属。
配置注入与一次构建多处部署配套：代码里残留的环境分支会破坏制品晋级的前提。
敏感配置与普通配置分级管理：凭据走密钥管理注入，普通配置走配置中心或环境变量，别混在同一层级。