配置写在代码里的第 100 天，我终于建了配置表

复盘一个老项目，发现一个难堪的规律：过去半年的 47 次发版里，有 21 次只是改了一个数字——限流阈值、缓存时长、白名单、重试次数。这些"配置"当初都被当成了代码写死，改一个就要走完整条发布流程。

于是把"什么该进配置"整理成三条判断：

• 运营会调的（阈值、开关、白名单）→ 配置表或配置中心，改完即时生效
• 环境相关的（连接串、域名、路径）→ 环境变量/环境配置文件，跟环境走
• 逻辑的一部分（算法参数、协议常量）→ 留在代码里，改它就是改行为，理应走发布

配置化之后的第一个坑是配置失效：改了配置，代码还在用启动时缓存的旧值。所以每个配置项要有明确的生效方式——定时刷新、变更回调、还是重启生效，写进配置项的注释里。第二个坑是配置没有默认值，漏配直接崩——所有配置读取必须带默认值和类型校验。

还有一个容易被忽略的点：配置也要能回滚。配置中心里改错了参数引发故障，回滚配置应该和回滚代码一样是一键的事。带历史版本和一键回滚的配置中心，才算及格。

那次改造之后，发版次数降了一半以上。发版应该承载"逻辑变更"，而不是"改个数字"。如果你们也经常为改数字发版，这篇是给你的信号。