7.0 KiB
配置频繁变更场景下的后台管理方案
文档版本：v1.0 最后更新：2026-04-02 08:28:05
本文用于整理一套更适合“配置项变化很频繁”的后台方案。
适用前提：
- 配置驱动型应用
- 游戏规则和字段会持续变化
- PostgreSQL 作为主数据库
- Go 作为中间层
- 客户端最终读取静态 JSON
核心目标是：
在保证后端稳定的前提下，让前端和玩法配置可以持续快速迭代。
1. 核心原则
这版方案的核心思想只有一句：
后端管理“容器、版本、引用、发布”，不要深度管理每个细字段。
也就是说：
- 后端负责管理对象关系
- 后端负责管理版本和发布
- 后端负责做基础校验
- 后端尽量不要写死每个玩法里的所有字段细节
2. 总体结构
推荐分成 3 层：
2.1 编辑层
后台管理系统面向的是“对象”，不是最终运行文件。
建议核心对象仍然是：
MapPlayfieldGameModeResourcePackEvent
2.2 装配层
Go 中间层负责：
- 读取对象
- 合并引用
- 基础校验
- 生成最终运行态配置
2.3 发布层
装配完成后，生成静态 JSON 上传到 OSS/CDN。
客户端只读取：
- 已发布的静态配置
3. 数据库存什么
数据库建议只存两类数据：
3.1 稳定元信息
结构化列保存：
idslugnamestatuscurrent_version_idcreated_atupdated_at
3.2 易变配置内容
使用 jsonb 保存：
content_jsonb
也就是说，每个对象都建议拆成：
- 主表
- version 表
例如：
maps/map_versionsplayfields/playfield_versionsgame_modes/game_mode_versionsresource_packs/resource_pack_versionsevents/event_versions
这套结构最适合承接频繁变化的配置字段。
4. 为什么要用 version 表
配置频繁变化时，版本表非常重要：
- 支持草稿
- 支持当前版
- 支持发布版
- 支持历史回滚
- 支持 diff
- 支持审计
如果没有版本表，配置演进到后面会越来越难控。
5. 后端真正该负责的内容
后端建议强管理下面这 4 件事：
5.1 对象关系
例如：
- Event 引用哪个 Map
- Event 引用哪个 Playfield
- Event 引用哪个 GameMode
- Event 引用哪个 ResourcePack
5.2 版本机制
例如：
- 草稿
- 当前版本
- 发布版本
- 回滚历史
5.3 基础校验
只做真正稳定的校验：
- 顶层结构是否合法
- 引用是否存在
- schemaVersion 是否兼容
- 必填对象是否齐全
5.4 发布装配
把编辑态对象装配成最终运行态 JSON。
6. 后端不要过度负责的内容
后端不要把下面这些写死：
- 每个玩法的小规则字段
- 每个 HUD 开关
- 每个实验性参数
- 每个视觉细节配置
- 每次快速迭代里新增的小配置项
这些变化太频繁，应该优先放在 jsonb 内容里，由前端消费。
一句话：
后端不要成为“所有细字段的业务解释器”。
7. 配置校验的推荐分层
建议分成 3 层校验。
7.1 通用结构校验
所有配置都校验：
schemaVersionmapplayfieldgame
7.2 公共字段校验
只校验稳定公共字段，例如：
game.mode必须存在game.punch.radiusMeters > 0
7.3 玩法校验器
按 game.mode 分发，例如：
classic-sequentialvalidatorscore-ovalidator
但这里有个重要原则：
未识别字段默认允许透传。
也就是说：
- 不要因为多了一个新字段就发布失败
- 只有破坏基础结构或关键规则时才拦截
8. 后台编辑策略
后台不要追求“一开始把所有字段都做成完美表单”。
建议分成两类：
8.1 稳定字段
做正式表单：
- 名称
- 状态
- 模式
- 地图引用
- Playfield 引用
- 资源包引用
- 关键半径
- 是否必须起点/终点
8.2 易变字段
先保留模块化 JSON 编辑区：
game.sequencegame.guidancegame.visibilitygame.feedbackplayfield.controlOverrides- 其他试验性字段
等这些字段稳定后，再逐步升级成正式表单。
这会比一开始硬做全表单更现实。
9. 推荐的发布模型
建议增加一层：
event_releases
推荐字段：
idevent_idevent_version_idrelease_nomanifest_urlpublished_bypublished_atstatus
发布流程：
- 后台选择某个
event_version - Go 层装配最终配置
- Go 层校验
- 上传 OSS/CDN
- 写入 release 记录
客户端只消费：
- 某次 release 对应的静态 JSON
10. Go 中间层的职责
Go 中间层建议承担 4 类职责：
10.1 装配器
负责把：
MapPlayfieldGameModeResourcePackEvent Overrides
装配成最终运行态配置。
10.2 校验器
负责：
- 通用校验
- 公共字段校验
- 按玩法分发的插件式校验
10.3 发布器
负责：
- 生成静态 JSON
- 上传 OSS/CDN
- 写入 release
10.4 预览 / Diff
负责：
- 给后台看发布前的预览
- 对比不同版本差异
一句话：
Go 中间层本质上是配置编译器，不只是 CRUD 服务。
11. 这套方案为什么适合当前项目
因为当前项目的真实情况就是：
- 配置字段变化快
- 玩法在持续演进
- 前端经常需要新增规则项
- 客户端更适合消费静态配置
如果后端每次都跟着细字段改表、改结构、改接口，成本会非常高。
这套方案可以避免：
- 频繁 migration
- 后端字段爆炸
- 每次小字段变更都改很多 Go 代码
12. 推荐你现在就定死的原则
原则 1
数据库结构稳定，配置内容灵活。
原则 2
后端强管理对象关系，不强管理每个细字段。
原则 3
未知字段默认允许透传。
原则 4
客户端消费细规则，后端负责发布与校验。
原则 5
最终运行态永远是静态 JSON。
13. 和当前目录结构的关系
如果当前静态目录是：
map/kml/event/
这套可以继续保留。
理解方式是：
- 数据库 = 编辑态
- Go 装配 = 发布态转换
- OSS 目录 = 运行态产物
也就是说后台发布后，继续生成：
event/classic-sequential.jsonevent/score-o.jsonmap/...kml/...
客户端现有读取逻辑无需推翻。
14. 推荐实施顺序
建议按下面顺序推进：
第一步
先建 5 个核心对象：
MapPlayfieldGameModeResourcePackEvent
第二步
为每个对象补 version 表。
第三步
Go 中间层先做最小装配功能。
第四步
实现发布到 OSS/CDN。
第五步
后台逐步把稳定字段表单化。
第六步
把易变字段继续保留为 JSON 编辑区。
15. 一句话总结
这套更适合频繁变化配置项的后台方案是：
PostgreSQL 存“版本化对象 + jsonb 内容”，Go 中间层做“装配 + 校验 + 发布”，客户端只读静态发布结果。