环境变量配置方式
以环境变量传递配置：语言无关、容器友好、平台原生支持；注意命名规范、类型转换与长度限制等边界。优点：与进程环境天然集成，是十二要素实践的标准做法，云平台与容器编排原生注入。局限：全部是字符串（类型自行解析）、命名空间扁平、排查时可能被日志与转储带出。规范建议：统一前缀（如 APP_）、明确类型约定、敏感项配合掩码。变量数量超过几十个之后维护成本上升，多而复杂的配置更适合结构化配置文件加密钥分离。
基本信息
| 优点 | 与进程环境天然集成；云平台与容器编排原生注入 |
|---|---|
| 局限 | 全部是字符串（类型自行解析）；命名空间扁平 |
| 风险 | 排查时可能被日志与转储带出，敏感项要掩码 |
| 规范 | 统一前缀、明确类型约定、启动时校验 |
| 规模边界 | 数量超过几十个后适合改用结构化配置文件 |
典型使用场景
- 容器与编排：Kubernetes 的 env 与 envFrom 原生注入，配置与镜像分离。
- 多环境部署：同一镜像靠变量区分环境，制品保持不变。
- 临时开关：调日志等级、功能开关等快见效参数。
- 受限环境：无卷或只读文件系统时仍能注入配置。
- 平台集成：CI 平台与云服务按变量注入凭据，配合掩码使用。
- 排查辅助：启动时输出已加载的变量名清单（不输出值），核对注入是否生效。
示例
示例
export APP_LOG_LEVEL=info
export APP_DB_POOL_SIZE=20
# 应用内：类型转换与默认值在代码统一处理
# 启动时校验：缺关键变量直接失败退出变量数量超过几十个后维护成本上升：多而复杂的配置更适合结构化配置文件加密钥分离。
类型转换易错：字符串到数字与布尔的解析规则要统一，非法值应启动即失败而不是运行中报错。
变量值不进镜像与仓库：由部署层注入，凭据走密钥管理，代码只读变量名。