figcraft

FigCraft：用纯 Rust 重铸协作设计底座的野心与代价

项目背景与痛点

Figma 把设计工具搬进浏览器，顺带把“协作”从锦上添花变成了基础设施。但它的内核始终是闭源 SaaS，这对想把设计协作能力嵌入自身产品的团队意味着两座大山：不可控的数据主权，以及无法二次开发的封闭管线。FigCraft 的定位一句话就说清了——open-source, clean-room reimplementation in pure Rust。其中“clean-room”是极关键的信号：不抄代码，基于公开的交互语义从零重建一套协作设计工作流。

那为什么非得是 Rust？协作设计工具的真正矛盾，从来不是界面有多花哨，而是**“实时同步的确定性”与“渲染吞吐的稳定性”之间的拉扯**。多人光标以毫秒级抖动；一次 Canvas 重绘如果被 GC 停顿打断，协作体验就会立刻崩塌。Rust 的零成本抽象、可预测的内存布局、无 GC 运行时，恰好同时切中这两个痛点——这也是作者选择纯 Rust 而非 TS + WebComponents 的根本原因。

核心技术揭秘

从“纯 Rust + 协作设计”这两个约束反推，FigCraft 大概率的骨架是命令驱动 + 文档状态 + 增量渲染的三层结构，而不是把设计稿当成一大坨可变的 DOM 树。这一选择决定了它能否撑住高频协同。

这张图里最值得推敲的是 D 处的状态引擎。设计稿天然是一棵层级树（画板 → 图层 → 组 → 元素），要支持多人并发编辑同一父节点下的兄弟节点、调整同一元素的不同属性，传统 OT 方案需要中心服务器串行化所有操作，代价是延迟与单点依赖。FigCraft 若要兑现“协作优先”，大概率要走 CRDT 路线：给每个节点分配稳定的逻辑 ID，把属性变更表达为可交换、可结合的操作，最后在本地或对端做无冲突合并。难点不在合并算法本身，而在于“树结构 CRDT”在移动节点、父子换绑时的收敛性——这是学术上一直头疼的问题，也是净室实现里最容易翻车的地方。

另一个隐蔽的工程点在于 E 到 F 的增量提取。协作场景下每秒钟可能有上百个操作，如果每次变更都整树重绘，Rust 带来的性能红利会被瞬间吃光。合理的实现一定会维护脏区域/脏节点集合，配合类似 R-tree 或四叉树的空间索引做命中测试与裁剪，让渲染只对变化部分动手。至于渲染后端，纯 Rust 生态里 wgpu 几乎是唯一正确解——同一套代码既能编译成 wasm 跑在浏览器，又能原生落地桌面端，这与项目“跨端”的野心高度自洽。

功能亮点与差异

第一，净室重写本身就是差异化。市面上不少“开源 Figma”是逆向或直接套壳，许可证与合规风险始终悬在头上；净室实现意味着代码可以放心作为商业产品的基石，这一点的长期价值被严重低估。

第二，库化而非应用化。纯 Rust 实现天然可以沉淀为 embeddable 的 crate。你拿到的不是又一个“在线白板”，而是一套可嵌进你产品里的协作设计内核——这对想做垂直行业设计工具（装修、服装、工业绘图）的团队是刚需。

第三，性能确定性。无 GC、可预测的延迟，加上 wgpu 的跨端渲染，让它在低端移动设备、私有化部署场景下比 Electron/WebGL 方案更可控。

应用场景与落地建议

它适合三类场景：自托管的内部设计/白板协作（数据不出内网）、嵌入到垂直 SaaS 的设计模块、以及桌面端高性能绘图。

生产环境要留意几点：其一，协作一致性要重点压测，特别是并发移动图层、同时删除父节点这类对抗性操作，CRDT 的边界行为必须显式验证；其二，持久化与快照策略要独立设计，CRDT 状态体积会随时间膨胀，缺少压缩/快照机制会导致文档越用越慢；其三，生态成熟度——纯 Rust 的 UI 框架与插件体系远不如 Web 端丰富，若你的团队需要大量富交互控件，要做好自研准备。

综合评价

优点：技术选型精准（Rust + wgpu + CRDT 的组合逻辑自洽），净室实现带来干净的许可证与商业可用性，库化定位切中垂直应用的真实缺口，性能天花板高。

缺点：协作一致性这类“深水区”问题没有捷径，实现难度被低估的风险极高；生态与插件体系薄弱，短期难形成网络效应；纯 Rust UI 的交互开发效率不及 Web 栈，迭代成本偏重。

一句话总结：FigCraft 不是要再造一个 Figma，而是想把“协作设计的内核”做成一块可被 Rust 生态复用的底盘——野心是对的，代价也是真实的，能否扛过去，取决于它在 CRDT 收敛性与渲染增量这两个硬核难点上是否足够扎实。