后台可配置化设计：哪些内容应该进配置中心

“所有东西都能配置”会把产品变成表单迷宫，也可能把本应固定的安全策略交给普通运营修改。配置的价值是让有权限的人在不发版时调整低风险、频繁变化的内容，同时保留验证、审计和回滚能力。

判断是否值得配置

适合配置：主页标题/文案、导航入口、每日提醒、主题颜色、已授权背景图、AI 资讯来源与质量阈值、阅读器字号默认值、实验室介绍等。前提是存在明确 owner、合理更新频率和默认回退值。

需要谨慎或保持代码约束：角色授权核心、文件访问策略、任意脚本、SQL、回调 URL、网络代理目标、加密参数、部署端口、数据库 schema。可以暴露有限开关或选择项，但不能让任意 JSON 变成远程执行能力。

每项先写责任人、消费页面、数据类型、可见范围、默认值、取值边界、风险等级、缓存时长、是否需要重启、历史版本和回滚动作。低变更频率但高风险的设置不一定要做成面向运营的编辑器。

使用 schema 校验数据

对输入验证完整 JSON 结构：必填字段、类型、枚举、长度、数字范围、数组数量和未知字段策略。前端表单校验用于及时提示，后端保存前必须用同一契约或生成的类型再次校验。读取旧数据时要有版本迁移和安全默认，不能因一个字段缺失让整个站点报错。

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "additionalProperties": false,
  "required": ["enabled", "maxItems"],
  "properties": {
    "enabled": { "type": "boolean" },
    "maxItems": { "type": "integer", "minimum": 1, "maximum": 30 },
    "sources": {
      "type": "array",
      "maxItems": 20,
      "items": { "type": "string", "maxLength": 500 }
    }
  }
}

JSON Schema 中 format 的实现可能仅作注释，不能假定日期、URL 或邮箱一定完成语义校验。涉及 URL 的字段要限制协议、host 和回环/私网地址，并防 SSRF；涉及媒体要检查 MIME、尺寸和存储授权。

权限、审计和版本

配置读取按公开、登录、编辑者、管理员分区；敏感字段从公开 API 彻底剔除，不只是 UI 隐藏。保存接口检查角色和字段级权限，拒绝未知字段；记录 actor、配置组、版本、变更字段、理由和时间，不记录秘密原值。更新涉及权限、审核阈值或数据抓取的配置要可预览，显示影响范围并支持恢复上一版本。

配置变更要有乐观锁或版本号避免多人覆盖；后台保存成功不等于 CDN、进程内缓存和静态页面已刷新。明确缓存 TTL、失效消息、重试和最终一致时间。高风险配置需双人确认或限时生效；系统启动时缺配置要选安全默认，而非自动放宽权限。

验收场景

测试缺失配置、空数组、错类型、旧版本 JSON、多余字段、极长内容、越界数字、无权限修改、并发保存、缓存失效失败、回滚、公开 API 泄露和服务重启。分别检查管理员编辑器、VIEWER 预览、公开页面和移动端布局。

为每个配置组保留有效/无效 fixture，并测试旧 schema 升级。公开接口采用 allowlist 响应模型，不直接序列化数据库 JSON；更新使用版本号避免并发覆盖。影响页面时提供草稿预览，只有显式发布才更新公众版本。缓存失效失败要显示当前实际生效版本并支持重试，避免把“保存成功”误解为全站已经刷新。

参考：JSON Schema 类型与校验、OWASP Authorization Cheat Sheet。