canvas-editor：用 Canvas 重写富文本编辑器，换来了什么

它解决的是 contenteditable 解决不了的问题

浏览器自带的 contenteditable 让富文本编辑变得容易，但也把排版控制权交给了浏览器。不同浏览器对字体、行高、分页的处理不一致，打印结果经常和屏幕显示对不上。canvas-editor 把整个渲染管线接管过来，用 Canvas 绘制每一个字符、表格和图片。README 明确列出了对比：跨浏览器渲染像素级一致、原生分页、打印保真、排版完全可控。这不是为了炫技，而是给电子病历、法律合同、报告这类文档应用准备的。这类应用里，一个分页符的位置错了，或者打印出来的页边距不对，就是事故。canvas-editor 的目标就是让屏幕上的样子和打印出来的样子一致。

渲染架构：draw、command、event 三层各管什么

从项目结构看，src/editor 下分了 core、command、event、observer 四个目录。core/draw 是渲染引擎，里面又细分了 particle（文本、图片、表格、LaTeX 的元素渲染器）、control（表单控件渲染）、frame（页边距、背景、边框）、richtext（下划线、高亮等装饰）、interactive（搜索、涂鸦）。command 目录用命令模式管理操作，比如 executeBold、executeUndo，这样撤销重做可以统一处理。event 处理 Canvas 和全局事件，observer 负责鼠标、选区、图片的观察。这个分层和传统 DOM 编辑器完全不同。DOM 编辑器里，浏览器替你处理了布局和事件，你只需要操作 DOM。canvas-editor 里，所有命中测试、选区绘制、光标闪烁都要自己实现。文档提到 Web Worker 用于字数统计、目录生成和异步取值，说明长文档的性能压力已经被考虑到了。

快速上手：三行代码创建一个编辑器

安装依赖用 npm、pnpm 或 yarn 都行，包名是 @hufe921/canvas-editor。快速开始的例子很简单：先放一个 div 容器，然后 new Editor(container, { main: [{ value: 'Hello, Canvas Editor!' }] })。构造函数接受容器和初始文档数据，main 数组里是段落对象。这个数据格式意味着文档结构是 JSON，不是 HTML。这会带来一个迁移成本：如果你有现成的 HTML 内容，需要转换成这种结构。README 没有提供转换工具，文档站可能有，但仓库里没写。开发环境要求 Node.js 大于等于 24.13.1，用 pnpm 安装依赖，npm run dev 启动。构建库用 npm run lib，跑测试有 Vitest 单元测试和 Cypress 端到端测试。这些命令都是标准的，没有特别之处。

功能清单：从表格到表单控件，覆盖文档编辑的常见需求

README 列出的功能很全：撤销重做、字体字号、粗体斜体、下划线、删除线、上下标、对齐、标题、列表，这些是基础。插入元素包括表格、图片、超链接、代码块、分页符、LaTeX 数学公式、日期选择器、块元素。表单控件有下拉选择、文本框、日期、单选、复选。分页是原生的，支持页眉页脚和页码。页面布局可配置页边距、水印、背景。文档结构支持目录生成、评论和分组批注。打印导出通过 canvas 转图片或 PDF 实现。交互方面有自定义右键菜单、可定制快捷键、文本和元素的拖放。插件系统用于扩展功能。这个功能集明显偏向正式文档场景，不是博客编辑器。

一个明显的代价：自绘渲染的维护成本

canvas-editor 把渲染完全握在自己手里，好处是跨浏览器一致，坏处是每个新功能都要自己画。对比 contenteditable 编辑器，浏览器帮你处理了光标、选区、输入法合成、复制粘贴的很多细节。canvas-editor 里这些都要在 event 和 observer 层自己实现。README 里提到 feature/svg 分支在开发中，说明渲染层还在演进，可能未来会从 Canvas 切到 SVG 或两者并存。这意味着底层渲染 API 可能变化，依赖它的项目需要跟着升级。另外，Canvas 渲染对可访问性不友好，屏幕阅读器读不到 Canvas 里的文本内容，除非额外实现 ARIA 或隐藏的 DOM 副本。README 没有提无障碍支持，这是一个需要自己验证的盲区。

替代方案：不是所有场景都需要 Canvas

如果你不需要分页和打印保真，传统的 contenteditable 编辑器如 TipTap 或 Slate 是更轻的选择。它们基于 DOM，浏览器处理了大部分交互细节，开发效率高，生态里有很多现成插件。但它们的分页能力弱，打印样式需要额外调 CSS，跨浏览器渲染不保证一致。另一个方向是 ProseMirror，它用 Schema 约束文档结构，适合结构化编辑，但排版控制不如 Canvas 彻底。canvas-editor 的取舍很明确：用开发复杂度换渲染确定性。如果你的应用是内部工具，用户能接受浏览器差异，那 contenteditable 就够了。如果是面向客户的正式文档产品，canvas-editor 的投入才划算。

维护与升级：许可证和分支带来的不确定性

项目采用 MIT 许可证，商用没有法律障碍。但仓库没有列出最近的 release，README 提到 1.0.0 已发布，有专门的发布说明文档。开发分支 feature/pdf、feature/ai、feature/CRDT 分别对应 PDF 导出、AI 处理和 CRDT 协作，都在开发中。这些功能如果进入主线，会改变 API 或数据格式。依赖这个项目，你需要关注这些分支的进展，因为它们可能带来 breaking changes。文档站 hufe.club/canvas-editor-docs 是唯一完整的 API 参考，但它是个人站点，不是 CDN 托管的稳定文档。如果作者停止维护，你的团队需要有能力读懂 TypeScript 源码并自己修复问题。这要求团队有 Canvas 编程经验，不是每个前端团队都具备。

编辑结论

canvas-editor 适合需要 Word 式分页、页眉页脚、目录和表单控件的浏览器应用，尤其是电子病历、合同和报告这类文档密集型产品。不适合只需要轻量文本编辑、团队没有 Canvas 渲染经验或依赖浏览器原生可访问性的项目。采用前先验证三件事：用你的真实文档跑一遍分页和打印导出，检查水印和目录在长文档下的性能，确认 Web Worker 的异步取值是否符合你的数据流。该项目的 MIT 许可允许商用，但自绘渲染意味着每个新交互都要自己实现，这不是一个开箱即用的组件，而是一个需要持续投入的渲染框架。

官方来源

1. Official documentation
2. Official README
3. Project repository