自研vsKonva-Fabric-Pixi

缺的不是 API，是 场景图、命中、历史记录、导出。库能买到这些，也会把你锁进它的对象模型和渲染循环。

1. 怎么选

需求	倾向
少量自定义绘制 + 自己已有 scene	自研 Canvas 2D
需要变换手柄、成组、序列化，产品就是编辑器	Konva 或 Fabric
大量精灵、粒子、交互游戏	Pixi（WebGL，2D context 不够）
必须无障碍、可选文本	不要这些库当 DOM
导出要像素级自己控滤镜	自研或只把库当预览

type Stack = "custom-2d" | "konva" | "fabric" | "pixi";

export function chooseRenderer(input: {
  editorChrome: boolean;
  spriteCount: number;
  pixelFilters: boolean;
  existingSceneGraph: boolean;
}): Stack {
  if (input.spriteCount > 5_000) return "pixi";
  if (input.existingSceneGraph && !input.editorChrome) return "custom-2d";
  if (input.pixelFilters && !input.editorChrome) return "custom-2d";
  if (input.editorChrome) return "konva";
  return "custom-2d";
}

数字是量级信号，不是基准。5k 简单矩形在 2D 上可能仍够；5k 带阴影滤镜的照片就不行。

2. 各库实际买到什么

Konva
场景图 + 层 + 变换器（Transformer）成熟。事件是它自己的，和 Pointer Events 不完全同一套。导出 toDataURL 仍受 taint 约束。适合白板/设计工具原型。自定义像素滤镜要跳出节点树自己搞离屏。

Fabric.js
对象模型偏「画布上的图元」，序列化 JSON 开箱即有。文本编辑比 Konva 顺。版本跨越时对象 schema 要自己迁移。大列表（几百复杂 path）会在 JS 对象和 2D 光栅之间两头烧。

PixiJS
渲染器是 WebGL/WebGPU，不是 CanvasRenderingContext2D。你在本体系学的 CTM/willReadFrequently 不能 原样搬过去。粒子、骨骼、滤镜 shader 才是它的主场。UI 编辑器硬用 Pixi 会把简单矩形变成纹理上传问题。

Paper.js / Rough.js / Svg.js
Paper 是矢量运算友好；Rough 是风格化描边。它们解决的是几何/风格，不是高 DPI 产品壳。可以当生成 path 的库，光栅仍走你自己的 ctx。

3. 自研时不要重新发明的部分

即使不用 Konva，也要有：

• 相机与锚点缩放
• 指针状态机 + capture
• 命令栈撤销
• 分层（静态/动态）
• 导出走干净表面

库内部仍是立即模式。把「用了 Konva」当成「不用懂 backing store」会在 Retina 和导出上翻车。DPR、taint、OffscreenCanvas 规则不变。

4. 失败形态

症状	原因
上了 Fabric 仍然糊	没设其 pixelRatio / 没跟 DPR
Pixi 里 getImageData	那是 GL 读回，成本模型全变
库的 toJSON 当唯一数据源	业务字段丢失，协作 crdt 对不上
两个 rAF 循环	库有自己的 stage.draw，外面又写了一个

权威资料

• Konva docs
• Fabric.js docs
• PixiJS docs

核对日期：2026-08-26