一张大表单的三种死法

早期配置页是"一张表单 + 上百个输入框"，很快出现三种问题：

1. 找不到："短信签名在哪配？"——只能靠 Ctrl+F 在页面上搜；
2. 误改：滚动时手滑改掉一个值，保存后全站异常；
3. 不敢改：支付密钥和"首页标语"放在一起，权限无法区分。

配置项本身的复杂度不高，问题出在没有结构。

按"谁来改"分组，而不是按"存在哪张表"

分组的第一原则不是技术分类，而是使用者的心智。我们最终切成 10 组：

按人分组的好处是：权限可以按组分配。财务只开"支付设置"，运营看不到密钥类配置。

敏感项要单独处理

密钥类配置（支付私钥、地图 Key、AI Key）有三条硬要求：

• 展示脱敏：列表只显示后四位，点"编辑"才可写；
• 留痕：谁在什么时候改过哪一项；
• 不回显原文：接口返回掩码，避免浏览器或日志泄露。

这几条不是"安全加分项"，而是客户安全审计必查项。

改完必须立即生效

上线后遇到过一个典型问题：管理员在「上传设置」里加了 md 扩展名，上传仍提示不支持。原因是上传校验读了缓存里的旧配置。

处理原则是：配置读取分两类——

• 低频、可缓存（站点名、LOGO）：缓存 5 分钟，性能优先；
• 强时效（上传白名单、开关类）：每次直读，保存后立即可用。

用一套缓存策略覆盖所有配置，一定会出现"改了没生效"。判断标准是：这个配置改错会造成什么后果？会造成"功能不可用"的，就必须即时。

配置项的生命周期

配置也是数据，需要和表结构一起管理：

• 新增配置项要写默认值，否则老部署升级后取到空字符串；
• 废弃配置项先下标记，确认无人引用再删；
• 配置项的名称要稳定，它是代码里的读取键，改名等于改代码。

我们把配置项的初始化放进迁移脚本，而不是靠"第一次打开页面时自动创建"——后者会让不同环境的配置顺序不一致，排查问题时很难对齐。

小结

配置中心的价值不在"能改"，而在改得对、改得安全、改完生效。按使用者分组 + 敏感项脱敏 + 强时效项直读，这三点做到，配置页就不会变成事故来源。