Web端PPT应用画布方案：Canvas 还是 DOM？

我最近在做一个web端的PPT项目，其中最重要的就是编辑器画布的技术选型

摆在面前的有两个选择：

1. 一个是DOM+Position定位
2. canvas引擎

坦白讲刚开始我是选择了canvas引擎这种方案，然后canvas引擎选择的时候leaferjs,当时思考的比较简单，canvas肯定比dom有性能优势，然后就开始了初步的尝试

但是很快就遇到了一些问题

• 复杂的状态管理canvas引擎的数据不容易被掌握
• canvas如果不用第三方引擎事情就会变的很复杂
• 如果用canvas现成的引擎，他的数据格式定死了，不一定能够满足你的要求、习惯等等
• 编辑组件状态不容易被获取到，并没有获取dom的click等原生HTML事件来的容易
• 第三方canvas引擎的学习成本，当然这有助于学习canvas技术
• canvas对于富文本的支持有限
• 使用dom我可以随心所欲

脑子里有一个声音异常强烈：TMD改成DOM+Position吧，学习canvas引擎咱专门去学一下好不好

因为对于PPT这样的"文档型"应用来说，DOM在功能完备性和开发效率上的优势，往往远大于Canvas在极限性能上的优势。

优势一：原生的富文本能力

这是DOM方案的"杀手锏"。一个设置了 contenteditable="true" 的 <div>，或者一个集成了 Tiptap / Quill 这样富文本编辑器的组件，免费提供了Canvas梦寐以求的一切：

• 文本选择和光标
• 复制、粘贴、撤销、重做
• 混合样式（粗体、斜体、颜色）
• 段落、列表、行高

对于PPT应用来说，仅此一项，DOM方案就几乎胜出了

优势二：项目复杂程度低

• 状态与视图绑定： 每一个PPT元素（文本框、图片）就是一个 DOM 元素。
• 天然适配现代框架： 这与React、Vue等框架的工作方式完美契合。你的状态就是 [...objects]，你的视图就是 objects.map(obj => <div style={...}>...</div>)
• "移动"就是"移动"： 当用户拖动时，只需更新状态，框架会自动且高效地只更新那个 <div> 的 style 属性
• 事件处理： onClick？直接绑定在 <div> 上即可

优势三：更好的可访问性与调试

• 屏幕阅读器可以轻松阅读 <div> 里的文本。
• Ctrl+F 查找、右键菜单、浏览器扩展都能正常工作。

DOM方案真的会慢吗？

DOM方案唯一的"缺点"是潜在的性能问题：当一个页面上有成千上万个DOM节点时，浏览器会变慢。

但对于PPT应用，这个"缺点"几乎不成立

1. 对象数量可控： 一个PPT单页上有多少元素？几十个？顶多一两百个？这个数量级的DOM节点，对于现代浏览器来说毫无压力

只有构建的是像Figma那样（一个文档可能包含10万个图层）或在线游戏那样的应用时，Canvas的极限性能才变得有意义