配置管理：环境变量、配置中心与功能开关

配置混乱的典型症状：改一个超时时间要重新打包；测试环境连到了生产数据库；某个开关只在一台机器上生效。把配置分层管理，能避开大部分这类事故。

一、按变化频率和敏感程度分层

一条硬规则：密钥永远不提交到 Git。用 .env（已加入 .gitignore）、环境变量或密钥服务注入，代码里只留占位符。

二、默认值要合理且可覆盖

TIMEOUT = int(os.getenv("HTTP_TIMEOUT", "2"))

这样本地开发不用配任何东西就能跑，线上按环境覆盖。比把所有配置都写成必填要好——必填项一多，新人起项目就得先找一圈文档。

同时给配置加启动时校验：端口是不是数字、必填项有没有漏、取值是否在合法范围。让错误在启动阶段暴露，而不是等到某个请求打进来才炸。

三、功能开关不是配置项

开关（feature flag）和配置的区别是：它有生命周期，上线时打开、稳定后要删掉。

if flags.on("new_checkout", user_id):
    ...

要点：

• 按用户/租户维度放量，别只做全局布尔值
• 给每个开关登记负责人和预计下线时间
• 定期清理已全量放开的开关，否则半年后代码里全是没人敢删的分支

四、变更必须可追溯

配置中心要记录「谁在什么时间把哪个值从什么改成什么」，并支持一键回滚。很多线上故障不是代码发布引起的，而是有人改了一个配置值。

另外配置推送要有确认机制：改完看一眼生效实例数，别默认所有实例都收到了。

小结

静态配置随环境注入、动态值进配置中心、密钥单独管、开关带生命周期。分清楚这四类，配置就不会再变成事故源。