第一层：数据层 (The Source of Truth) - canvasStore.ts#

这是整个应用的大脑。

• 职责：只存储纯 JSON 数据（Serializable），不包含任何 UI 实例或 Pixi 对象。
• 存储内容：
  • elements: 一个 Map 对象（Record<ID, Element>），存储所有矩形、圆形的坐标、颜色等。
  • selectedIds: 当前选中的 ID 列表。
  • tool: 当前使用的工具。
• 特点：
  • 单一数据源：画布上显示什么，完全由这里的数据决定。
  • 无副作用：这里的 Action 只修改数据，不直接操作 DOM 或 Canvas。

第二层：适配层 (The Bridge) - StageManager.ts#

这是连接 React/Zustand 和 PixiJS 的胶水层，也是架构中最复杂的部分。

• 职责：将“声明式”的数据（Zustand）转换为“命令式”的 Pixi 调用。
• 核心机制 - 增量更新 (Diffing)：
  • 它维护了一个  spriteMap (Map<ID, PIXI.Graphics>)。
  • 订阅 (Subscribe)：它监听 Store 的变化。
  • 同步 (Sync/Render Loop)：
    • Create: Store 有 ID，Map 里没有 -> new PIXI.Graphics()。
    • Update: Store 有，Map 里也有 -> 更新  x, y, width, color。
    • Delete: Store 没有，Map 里有 -> destroy()。
• 事件转换：
  • 它监听 Pixi 的  pointerdown/move/up  事件，将屏幕坐标转换为逻辑坐标，然后调用 Store 的 Action。

第三层：视图层 (The Container) - Canvas.tsx#

这是 React 组件层。

• 职责：
  • 提供  div  容器供 Pixi 挂载。
  • 渲染 HTML UI（工具栏、属性面板）。
  • 生命周期管理：组件 Mount 时初始化  StageManager，Unmount 时销毁。

---

优点：#

解耦 (Decoupling)：渲染引擎可以随时替换（比如换成 Konva 或原生 Canvas），只需要重写  StageManager，数据层和 UI 层不需要动。

协同编辑 (Collaboration) 友好：

• 如果要实现多入协同，只需要监听 WebSocket 消息，然后更新 Zustand Store。StageManager  会自动把队友的操作画出来，无需写额外的同步绘图逻辑。 撤销/重做 (Undo/Redo) 容易：
• 因为所有状态都在 Store 里，只需要保存/恢复 Store 的快照（或 Patch）即可。 序列化/反序列化：
• 保存项目只需  JSON.stringify(store.elements)。

潜在挑战（及优化方案）：#

性能瓶颈：

• 问题：高频触发  Store Update -> Diff  循环可能在元素极多时（>2000 个）产生开销。
• 优化：对于拖拽这种 60FPS 的操作，可以引入“临时层” (Transient State)。即拖拽时直接修改 Pixi 对象，鼠标松开时再同步到 Store。 复杂性：
• 相比直接用 Canvas API 画图，这种架构代码量更大，需要维护 ID 映射和 Diff 逻辑。

feat(canvas): 重构画布实现，应项目要求，删除了基于tldraw的实现转而选择PixiJS 库重构以进行渲染操作，基于Zustand 进行状态管理。新增的文件中canvasStore.ts主要负责维护整个画布项目的全局可序列化状态，是渲染画布系统中唯一数据来源。Pixi_stageManager.ts 负责将声明式数据（Zustand）实时、高性能地映射为命令式渲染实例（PixiJS），并处理所有用户交互的计算与反馈。canvas下的index.ts最轻量的一层，仅负责生命周期管理与组件组装。三层数据驱动架构详情可见文档