如何从零开始打造一个富文本编辑器？

富文本编辑器是允许用户在输入和编辑文本内容时，可以应用不同的格式、样式等功能，例如图文混排等，具有所见即所得的能力。与简单的纯文本编辑组件<input>等不同，富文本编辑器提供了更多的功能和灵活性，让用户可以创建更丰富和结构化的内容。现代的富文本编辑器也已经不仅限于文字和图片，还包括视频、表格、代码块、附件、公式等等比较复杂的模块。 开源地址: https://github.com/WindRunnerMax/BlockKit 在线编辑: https://windrunnermax.github.io/BlockKit/ 项目笔记: https://github.com/WindRunnerMax/BlockKit/blob/master/NOTE.md 从零实现富文本编辑器项目的相关文章: 深感一无所长，准备试着从零开始写个富文本编辑器 从零实现富文本编辑器#2-基于MVC模式的编辑器架构设计 从零实现富文本编辑器#3-基于Delta的线性数据结构模型 从零实现富文本编辑器#4-浏览器选区模型的核心交互策略 从零实现富文本编辑器#5-编辑器选区模型的状态结构表达 从零实现富文本编辑器#6-浏览器选区与编辑器选区模型同步 从零实现富文本编辑器#7-基于组合事件的半受控输入模式 从零实现富文本编辑器#8-浏览器输入模式的非受控DOM行为 从零实现富文本编辑器#9-编辑器文本结构变更的受控处理 从零实现富文本编辑器#10-React视图层适配器的模式扩展 从零实现富文本编辑器#11-Immutable状态维护与增量渲染 Why? 那么为什么要从零设计实现新的富文本编辑器，编辑器是公认的天坑，且当前已经有很多优秀的编辑器实现。例如极具表现力的数据结构设计Quill、结合React视图层的Draft、纯粹的编辑器引擎Slate、高度模块化的ProseMirror、开箱即用的TinyMCE/TipTap、集成协同解决方案的EtherPad等等。 我也算是比较关注于各类富文本编辑器的实现，包括在各个站点上的编辑器实现文章我也会看。但是我发现这其中极少有讲富文本编辑器的底层设计，绝大多数都是讲的应用层，例如如何使用编辑器引擎实现某某功能等。虽然这些应用层的实现本身也会有一定复杂性，但是底层的设计却是更值得探讨的问题。 此外，我觉得富文本编辑器很类似于低代码的设计，准确来说是No Code的一种实现。本质上低代码和富文本都是基于DSL的描述来操作DOM结构，只不过富文本主要是通过键盘输入来操作DOM，而无代码则是通过拖拽等方式来操作DOM，我想这里应该是有些共通的设计思路。 而我恰好前段时间都在专注于编辑器的应用层实现，在具体实现的过程中也遇到了很多问题，并且记录了相关文章。然而在应用层实现的过程中，遇到了很多我个人觉得可以优化的地方，特别是在数据结构层面上，希望能够将我的一些想法应用出来。而具体来说，主要有下面的几个原因: 编辑器专栏 纸上得来终觉浅，绝知此事要躬行。 我的博客是从20年开始写的，记录的内容很多，基本上是想到什么就写什么，毕竟是作为平时学习的记录。然后在24年写了比较多的富文本编辑器的文章，主要是整理了平时遇到的问题以及解决方案，集中在应用层的设计上，例如: 初探富文本之文档虚拟滚动 初探富文本之OT协同算法 ... 此外，前段时间还研究了slate富文本编辑器相关的实现，并且也给slate的仓库提过一些PR。还写了一些slate相关的文章，并且还基于slate实现了一个文档编辑器，同样也是比较关注于应用层的实现，例如: WrapNode数据结构与操作变换 Node节点与Path路径映射 ... 在实现了诸多的应用层的功能之后，发现整个编辑器有很多可以深入研究的地方。特别是有些实现看似很理所当然，但是仔细研究起来会发现这其中有很多细节可以探究，例如在DOM结构后常见的零宽字符、Mention节点的渲染等等，这些内容都可以单独拿出来记录文章，这其实就是我想从零实现编辑器的最重要原因。 24年开始写了很多业务上的东西，到了25年就略感题穷，而目前我也没有别的擅长的方面，由此写编辑器相关的内容是比较好的选择，这样对于文章的选题也会简单些。不过，虽然想的是深入写编辑器相关的内容，但是在平时遇到问题的时候，还是会记录下来，例如最近有个基于immer配合OT-JSON实现的状态管理的想法可以实现。 而对于编辑器的具体实现，我目前的目标是实现可用的编辑器，而不是兼容性非常好且功能完备的编辑器。主要是现在已经有非常多优秀的编辑器实现，且有很多生态插件可以支持，能够满足大部分的需求。目前我想实现的编辑器主要是兼容Chrome浏览器即可，移动端的问题暂时不会考虑。