配置化活动平台：从页面复制到受控 DSL

在游戏平台里，活动规则、素材、时间、奖励和专区主题会持续变化。如果每次都复制页面并重新开发，短期看快，长期会形成重复代码、发布拥堵和版本漂移。配置化的目标不是“让 JSON 代替代码”，而是把稳定能力与高频变化分开。

先定义边界

适合配置化的是高频变化、结构相似、可被约束的部分：Banner、任务列表、排行榜、奖励展示、规则说明、按钮动作。复杂实时交互和一次性创意页面可以保留定制代码。

页面 DSL

interface ActivityPageSchema {
  schemaVersion: 3
  pageId: string
  theme: ThemeTokenSet
  dataSources: DataSourceConfig[]
  modules: ActivityModule[]
  release: {
    startAt: string
    endAt: string
    audience?: AudienceRule
  }
}

type ActivityModule =
  | { type: 'hero'; version: 2; props: HeroProps }
  | { type: 'task-list'; version: 1; props: TaskListProps }
  | { type: 'ranking'; version: 2; props: RankingProps }

每个模块有 type、版本和 props schema。编辑端根据 schema 生成表单并校验，运行端只解析白名单组件；事件通过受控 action 协议表达，不能允许任意脚本。

编辑、预览与运行共用内核

预览和线上如果使用两套渲染逻辑，很容易出现“预览正确、发布错误”。更稳妥的做法是共用 renderer，环境差异通过数据源适配和明确配置注入。预览必须展示当前 schema 版本、数据环境和权限身份。

版本、迁移和回滚

草稿 → 校验 → 预览 → 审批 → 发布 → 灰度/观察
  ↑                                  ↓
  └──────── 复制新草稿 ← 版本回滚 ────┘

• 发布版本不可变，编辑行为创建新草稿。
• 配置携带 schemaVersion，模块提供可测试的 migration。
• 发布前离线校验资源、接口、时间和权限。
• 回滚切换版本指针，而不是现场修改历史配置。

权限与审计

编辑、预览、审批、发布和回滚应是不同权限；关键操作记录操作者、差异、版本和时间。前端隐藏按钮只能减少误操作，接口仍要鉴权、校验和审计。

失败路径

• 未识别模块：显示受控占位并上报，不让整页崩溃。
• 资源加载失败：备用图/重试/跳过，并记录模块定位信息。
• 接口超时：模块级错误态，不阻断其他模块。
• 新旧版本错配：能力清单校验，不兼容时阻止发布。

如何证明收益

公开项目无法披露商业数字时，可以用可验证证据：同一模块服务多个专区、运营变更不再复制页面、版本能预览和回滚、模块拥有契约测试与错误边界。这比编造“效率提升 80%”更可信。