环境存档分离弊端：预览，正式，测试（加大自研编辑器重复工作量

自研编辑器 + 多环境部署 = 重复工作量翻倍的噩梦（我本来是打算用编辑器做了数据存档后，用我自己的号作为编辑器数据服务器的下载通用这些动画存档。结果，我忘了坏境存档分离。我的号在预览坏境无法直接编辑数据传到正式坏境。以自己的号作为数据存档这条路真要走，就要写三次数据，原本轻松的工作，一下重复了三倍）

一、背景我在做一个 2D 变形/动画编辑器（TAPTAP制造），用来给「星际歌姬」做角色动画。编辑器的产出是两类东西：

二、三个环境，三份存档TapTap 平台有三个独立环境：环境用途谁能用数据隔离预览环境扫码测试，快速验证开发者自己独立存档测试环境内测版本，邀请玩家测试白名单用户独立存档正式环境线上版本，所有玩家所有人独立存档关键词：独立存档。三个环境的云存档（serverCloud / clientCloud）是完全隔离的。预览环境上传的数据，测试环境看不到；测试环境的数据，正式环境看不到。

三、噩梦的本质：编辑数据要手动同步三遍如果选方案 B（编辑数据走服务器），工作流就变成了这样：我在编辑器里调好了一个头发飘动动画（本地）

  │

  ├──→ 上传到预览环境的云存档   ← 第 1 遍

  │      └── 扫码测试，发现动画过快

  │

  ├──→ 在编辑器里调整参数

  │

  ├──→ 重新上传到预览环境       ← 第 2 遍

  │      └── 预览没问题了

  │

  ├──→ 上传到测试环境的云存档   ← 第 3 遍

  │      └── 让内测玩家看看

  │      └── 反馈说眨眼太频繁

  │

  ├──→ 在编辑器里再次调整

  │

  ├──→ 上传到预览环境           ← 第 4 遍

  ├──→ 上传到测试环境           ← 第 5 遍

  │      └── 测试通过

  │

  └──→ 上传到正式环境的云存档   ← 第 6 遍

         └── 所有玩家可见

一个动画参数的调整，可能要手动上传 6 次。而且这还是理想情况——只改了一个动画。如果同时改了网格、动画、图层配置，每次上传都要确保三个数据完整一致。

四、自研编辑器让问题加倍普通游戏的多环境问题，通常只涉及代码和配置表。构建系统会自动处理：构建一次，部署到对应环境，完事。但自研编辑器的编辑数据不走构建系统。它是运行时产出——我在编辑器里拖拖拽拽产生的数据，不是源代码，构建工具不认识它。这意味着：普通游戏数据自研编辑器数据代码改了 → 构建 → 自动部署动画改了 → 手动导出 → 手动上传配置表改了 → 跟着构建走网格改了 → 手动导出 → 手动上传一次构建覆盖所有数据编辑数据要单独管理CI/CD 自动化纯靠人肉每多一个环境，编辑器数据的管理工作量就翻一倍。

五、具体翻车场景场景 1：预览环境数据是新的，正式环境忘了同步预览：data_version = 5   ← 最新的，刚测完

测试：data_version = 3   ← 忘了更新

正式：data_version = 3   ← 忘了更新

结果：

  自己扫码预览 → 完美（因为用的是最新数据）

  内测玩家测试 → 动画是旧的（data_version=3）

  正式玩家游玩 → 动画是旧的（data_version=3）

自己测试时感觉一切正常，上线后才发现不对

场景 2：三个环境的版本号各自跑偏预览：data_version = 8   ← 频繁测试，版本号飙升

测试：data_version = 5   ← 偶尔同步

正式：data_version = 3   ← 很少更新

某天要同步正式环境：

  - 预览的 v8 数据包含了 v4~v8 的所有改动

  - 但 v6 的一个改动是实验性的，不想上线

  - 需要手动挑选哪些改动要同步，哪些不要

  - 这已经不是简单的"上传"了，变成了数据的"分支管理"

场景 3：编辑数据和构建版本不匹配构建 v1.2.0 → 添加了新图层"翅膀"，对应新的网格类型

  预览环境：构建 v1.2.0 + 编辑数据 v8（包含翅膀网格）  ✓ 正常

  正式环境：构建 v1.1.0 + 编辑数据 v5（没有翅膀网格）  ✓ 正常（旧版本）

但如果手滑把 v8 的编辑数据上传到了正式环境：

  正式环境：构建 v1.1.0 + 编辑数据 v8

  → 编辑数据引用了"翅膀"图层和网格

  → 但构建 v1.1.0 的代码不认识这个图层类型

  → 玩家端崩溃或渲染异常

场景 4：调完动画忘了自己在哪个环境打开编辑器 → 调动画 → 导出 → 上传

  等等，我上传到哪个环境了？

  是预览？测试？正式？

编辑器本身不感知平台环境的概念

上传的时候全靠自己记住"现在应该传到哪里"

六、方案 A 的"笨办法"反而省心对比一下如果用方案 A（全部打包进游戏）：编辑器里调好动画

  │

  └── 导出 JSON → 放到 assets/data/ → 跟着游戏一起构建

       │

       ├── 部署到预览环境  ← 构建系统自动处理

       ├── 部署到测试环境  ← 构建系统自动处理

       └── 部署到正式环境  ← 构建系统自动处理

一次导出，构建系统自动处理三个环境的分发。 不需要手动管理版本号，不需要担心环境间数据不一致，不需要记住"我上次传到哪个环境了"。代价是：每次改动画都要重新构建发版。但在开发期和内测期，构建发版本来就很频繁。

七、那方案 B 就不能用了？能用，但要到合适的阶段，并且做好自动化。什么时候适合方案 B阶段推荐方案原因开发期A（打包）数据格式还在变，环境多了只会添乱内测期A（打包）发版频繁，打包最可靠公测/运营期B（服务器）内容稳定后需要热更新动画，不可能每次发版方案 B 的前提条件方案 B 想不翻车，至少需要：

八、核心矛盾自研编辑器的核心矛盾是：编辑器的产出物（编辑数据）游离在构建系统之外。普通游戏的所有内容（代码、资源、配置）都在构建系统管辖内，构建一次，三个环境自动分发。但编辑器的产出是运行时数据，构建系统看不见它。一旦需要手动管理这份数据的多环境同步，就掉进了"人肉 DevOps"的陷阱。三个环境 × 频繁迭代 × 纯手动管理 = 翻车概率极高。

九、我的选择现阶段：方案 A，全部打包。理由：

十、给同样做自研编辑器的人如果你也在做内置编辑器，并且平台有多个隔离环境：