可视化拖拽编辑器的数据模型：先想清楚再写代码

做拖拽式 UI 编辑器，最先要定的不是拖拽交互，是数据模型。模型错了，交互层写得再好也救不回来。我把这次设计的思路记录一下。 核心决策一：文档树还是扁平列表。文档树贴近渲染结构，嵌套直观，但跨层级拖拽时要处理大量边界情况——拖到自己的子孙里怎么办、拖拽过程中树结构怎么临时变更。扁平列表每个元素记录自己的父级和顺序，操作简单，但渲染时要自己重建层级。我选了扁平列表，因为拖拽是高频操作，简单比直观重要。 核心决策二：组件数据怎么存。两种方案，一是存全量数据，每个节点自带所有属性；二是存引用，节点只记录组件类型和参数，实现从组件库取。推荐后者，理由是组件升级时不需要迁移历史数据——改组件实现，所有引用它的页面自动生效。 核心决策三：撤销重做怎么实现。不要做双向操作（记录每个动作的正反操作），那种方案在复杂编辑器里一定会漏。用快照加差分：每次操作后存一份结构差分，撤销时反向应用。内存占用比全量快照小得多，实现也比双向操作简单。 核心决策四：协同编辑要不要一开始就支持。如果确定要做，数据结构从第一天就要按 CRDT 的思路设计，后面再改等于重写。如果暂时不做，也要在数据层留出操作日志的位置。 关于 agent 在这类项目里的位置：数据模型和撤销栈这种底层，适合让 Claude Code 写，因为它能一次性考虑全面并配上单元测试；拖拽手感和视觉反馈这类需要反复看的东西，适合在 MiMo Desktop 的实时预览里调，圈住哪里不对就改哪里。 一句话总结：编辑器的复杂度八成在数据模型，两成在交互。先把模型画在纸上讨论清楚，再开始写代码。