富文本编辑器选型与配置实战：从CMS到嵌入式设备

做Web开发这些年，富文本编辑器几乎成了每个项目都绕不开的组件。从最初在后台管理系统里塞一个TinyMCE应付内容发布，到后来在移动端、ERP系统、甚至嵌入式设备的Web管理页面里处理富文本，我踩过的坑比看过的文档还多。很多人觉得富文本编辑器就是个开箱即用的textarea升级版，实际上它的选型、配置、内容清洗、打印适配、资源占用，每一项都藏着大量细节。这篇文章不打算讲某个编辑器的完整API文档，而是从实际项目里提炼出"在不同的Web场景下，富文本编辑器到底该怎么选、怎么配、怎么适配"，把那些文档里不会明说、但真会上线踩雷的点一次性讲清楚。

1. 选型先想清楚：不同场景下的富文本编辑器怎么挑

很多开发者第一步就卡在选型上。GitHub上搜"富文本编辑器"能出来上千个仓库，每个都写着"功能强大、体验流畅、持续维护"，真到自己项目里一测，有的体积大到首屏崩溃，有的在移动端根本无法操作，有的在老版本浏览器里直接白屏。选编辑器不能只看Star数，得先回答三个问题。

1.1 轻量候选：wangEditor、Quill、TipTap各自适合什么场景

先说我自己用得最多的三个轻量方案。

wangEditor是国产编辑器里普及度最高的，文档全中文，API设计得很符合国内开发者的直觉。它的特点是开箱即用，npm安装之后，几行代码就能初始化一个带完整工具栏的编辑器。如果你做的是传统的后台管理项目、内容发布系统，对自定义能力要求不高，wangEditor是成本最低的选择。我可以直接给一个最基本的初始化示例：

import E from '@wangeditor/editor'; import '@wangeditor/editor/dist/css/style.css'; const editor = new E('#editor-container'); editor.config.placeholder = '请输入正文内容'; editor.create();

wangEditor的定制主要通过config对象完成。图片上传、菜单配置、内容回调都挂在config上，结构很清晰，适合快速交付。

Quill则是模块化做得最好的轻量编辑器。它本身的默认界面非常朴素，几乎就是一个白板，但通过注册模块可以实现几乎所有你能想到的功能。它的核心数据结构是Delta，一种纯JSON的记录格式，这意味着你可以很轻松地把编辑器的内容做增量同步、做协作编辑，甚至做操作历史回放。如果你的项目需要深度定制编辑体验，比如自定义一个流程图组件、插入一个自定义卡片，Quill的模块机制会给你非常大的自由度。Quill的初始化也很简洁：

import Quill from 'quill'; import 'quill/dist/quill.snow.css'; const quill = new Quill('#editor-container', { theme: 'snow', modules: { toolbar: [ ['bold', 'italic', 'underline'], [{ 'list': 'ordered' }, { 'list': 'bullet' }], ['link', 'image'] ] } });

TipTap是这三者里最"新派"的。它基于ProseMirror构建，完全采用Headless设计——不给你任何默认UI，只提供一套编辑能力核心，UI全部由你自己用JS框架渲染。这听起来很麻烦，但换来的是几乎无限的可定制性，而且它天然为Vue 3和React做了适配，是三者中与现代前端框架配合最自然的。代价就是学习曲线陡峭，你得懂Node、Mark、Extension这些概念，适合有足够时间打磨的团队。

给个直观的对比表格：

之所以先谈选型，是因为选型直接决定了后面所有配置工作的复杂程度。选错了，后面再怎么调优都像是在一个错误的地基上盖楼。

1.2 重量级选手：TinyMCE、CKEditor 5在复杂企业应用中的取舍

如果你做的是企业级的Web应用，比如在线文档系统、SaaS平台的富文本模块、或者功能完整的CMS后台，轻量编辑器往往会暴露出短板。这时候TinyMCE和CKEditor 5这两大重量级选手就进入了候选名单。

TinyMCE的优势是极其成熟的插件生态和长达十几年的浏览器兼容性积累。它的配置项相当丰富，从图片跨域上传到自动保存草稿、从拼写检查到国际化，几乎没有它做不到的。代价是初始体积惊人，即使按需加载，核心加基础插件也动辄三四百KB。但企业应用通常跑在内网，有这个体量换取稳定性和开发效率，在多数场景下是划算的。TinyMCE 6之后的初始化方式很清晰：

tinymce.init({ selector: '#editor-container', plugins: 'advlist autolink lists link image charmap preview anchor searchreplace wordcount code fullscreen insertdatetime media table', toolbar: 'undo redo | blocks | bold italic forecolor | alignleft aligncenter alignright | bullist numlist outdent indent | image media table | code fullscreen', height: 500, language: 'zh_CN', images_upload_url: '/api/upload/image', automatic_uploads: true });

CKEditor 5的现代感更强，它从底层就设计成了基于数据模型的内容处理引擎，输出的内容更干净、语义化更好。不管是团队协同、版本历史还是结构化文档，CKEditor 5都有官方或社区提供的成熟方案。它还有一个很实用的功能是Collaboration系列插件，可以把光标在线状态、评论、修订记录都做得很完善。但CKEditor 5的配置是建立在它的插件生态之上，自定义一个小组件需要理解它的事件机制和数据流，初期会有点痛苦。

结合这些年的实际经验，我的选型逻辑基本是这样的：只有明确需要丰富的批量插件能力或精细化协同功能时，才上重量级工具；如果一个内容发布后台仅仅需要段落排版、插图、加粗变色，强行引入TinyMCE反而会让页面卡顿，也让编辑团队觉得功能冗余。

另外值得多说一句的是，选型时一定要确认你对编辑器的"形态"需求。有的场景需要所见即所得，有的场景只需要Markdown编辑加预览，后者用md-editor-v3这类Markdown编辑器会更轻、更合适。富文本不等于一定要上富文本编辑器，这个判断力很重要。

2. 让编辑器听话的基础配置：初始化、双向绑定与布局还原

选好编辑器之后，第一个让人摔跤的地方就是初始化。很多人的第一反应是按照官方文档抄一遍，结果发现要么内容渲染不出来，要么数据取不到，要么编辑器高度跟预想的不一样。这些问题的根源，大多出在三个地方。

2.1 初始化的三个隐藏问题：容器尺寸、Vue响应式失效、组件复用

先说容器尺寸。富文本编辑器几乎都是基于iframe或contenteditable实现的，它们内部需要计算自己的布局，所以挂载编辑器的最外层容器必须有明确的高度。很多人只设置了宽度，期望编辑器自动撑开高度，结果初始化后只看到一条细线。解决方法是给容器一个最小高度，或者直接通过config配置高度，比如wangEditor：

editor.config.height = 500; editor.config.minHeight = 300;

Quill和TipTap则更建议在CSS层面控制：

#editor-container { height: 500px; } .ql-container { font-size: 14px; }

第二个坑是Vue或React框架下的响应式失效。富文本编辑器初始化时会把传入的数据渲染为DOM，但这个DOM是编辑器自己管理的，框架的数据绑定对它不起作用。常见表现是：data里的content改成了新值，界面上却不更新。这不是编辑器坏了，而是你需要手动调用API去设置或读取内容。以wangEditor为例，正确的同步方式是：

// 初始化时设置初始内容 editor.create(); editor.setHtml(initContent); // 操作完成后通过回调拿到最新内容 editor.config.onChange = (newHtml) => { // 这里再把 newHtml 同步给 Vue 的 data 或 React 的 state reactiveContent.value = newHtml; };

Quill的Delta结构是个例外，它的内容本身是JSON，如果你直接用setContents传Delta，数据模型是可控的，但如果你习惯用getSemanticHTML（Quill 2.0新提供的方法）拿HTML，同样要注意HTML字符串无法双向自动同步。

第三个坑是组件复用。编辑器一旦初始化挂载到DOM上，如果DOM被框架重新创建（比如弹窗关闭后v-if把节点销毁了），编辑器实例就变成了"幽灵"。正确做法是在组件销毁时机里调用编辑器自己的销毁方法。Vue 3的组合式API写法如下：

onBeforeUnmount(() => { editor.destroy(); });

如果你不销毁，可能会遇到编辑器实例复制后无法输入、事件重复监听、甚至内存泄漏等问题。

2.2 图片上传：谁说博客编辑器都要走后端？

图片上传是整个编辑器配置里最绕不开、也最容易写错的环节。大多数编辑器的默认行为是把图片转成base64直接嵌入HTML，这在小图时代没问题，但一张几兆的现场照片直接塞进文章，整个HTML会膨胀到几十兆，编辑起来卡、保存起来慢、数据库也扛不住。

正确的做法是配置上传到对象存储或后端接口。不同编辑器的配置方式不一样，以wangEditor为例，一般需要在customUpload里实现上传：

editor.config.customUpload = (file, insertFn) => { const formData = new FormData(); formData.append('file', file); fetch('/api/upload/image', { method: 'POST', body: formData }) .then(res => res.json()) .then(res => { if (res.code === 0) { insertFn(res.data.url, file.name, file.name); } }) .catch(err => { console.error('上传失败', err); }); };

关键点是编辑器并不关心你的上传接口是公司自研还是第三方图床，编辑器只负责把选中的文件交给你，然后由你把可访问的URL通过insertFn插回内容里。这个抽象设计得很好，你完全可以对接自己的后端、OSS、甚至Web3存储。

还有一个很常见的问题是图片跨域和防盗链。编辑器内容里插入的图片，如果前端页面与图片不在同一个域名，有些服务器的防盗链策略会把图片挡住。最省事的方案是使用自己的域名统一代理图片，或者在存储侧关闭明晃晃的防盗链。遇到过很多次，编辑器里图片正常显示，一到生产环境就裂图，排查半天结果是Referrer被拦了。

如果做的是轻量场景实在没有后端，只能用base64，那也一定要在数据提交前做一次大小校验。我一般会在customUpload里先判断file.size > 2 * 1024 * 1024，超了就弹窗提示，避免前端页面崩溃。

2.3 工具栏按需裁剪：配置量少一半，老用户反而更爽

每个编辑器的默认工具栏都是一整排——从加粗、斜体、下划线到表情、表格、代码块、视频、清除格式，堆得密密麻麻。问题是绝大多数场景下，用户根本用不到这么多功能，而且按钮越多，误操作越多，编辑界面看起来也越乱。

我建议按业务场景裁剪工具栏。比如一个内部知识库系统，可能只需要标题、加粗、列表、链接、图片这几样；面向运营人员的活动文案编辑器，可能需要更多的文字排版按钮；面向技术人员的文档编辑器，代码块和引用块的优先级就很高。

wangEditor的菜单配置可以通过设置menus实现：

editor.config.menus = [ 'head', // 标题 'bold', // 加粗 'italic', // 斜体 'list', // 列表 'link', // 链接 'image', // 图片 'code-block', // 代码块 'undo', // 撤销 'redo' // 重做 ];

Quill则在modules.toolbar里配：

modules: { toolbar: [['bold', 'italic', 'underline'], [{ list: 'ordered' }, { list: 'bullet' }]] }

这里有个容易踩的坑：编辑器的很多高级功能依赖配置项的支持。比如你保留了'上传视频'按钮，但没有配置视频上传的回调，用户点了往往没反应甚至控制台报错。我通常的做法是配置完工具栏后，挨个按钮点一遍，确认没有"孤儿功能"。这步做一次之后，哪怕换项目也不容易再犯。

3. 从编辑器到浏览器的一公里：内容展示、PDF打印与离线网页的坑

编辑器里编辑得再好，终归是要把内容拿到前端页面展示的。这一环节的坑比编辑器内部还多，因为编辑器输出的HTML是"为编辑器设计的"，不是"为展示设计的"。

3.1 v-html和安全过滤：配置项不能解决所有事

在Vue项目里，展示富文本内容最直接的方式是v-html，React对应的则是dangerouslySetInnerHTML。但这两个API都会原封不动地执行传入的HTML字符串，意味着如果内容被恶意写成<img src=x onerror=alert(1)>，这段脚本会在你的页面上执行。

这就是富文本内容的安全隐患。最严谨的做法是：内容入库前做服务端过滤，展示前做前端消毒。如果条件有限，至少在前端展示时用DOMPurify这类库做一次清洗。DOMPurify的使用很简单：

import DOMPurify from 'dompurify'; const cleanHtml = DOMPurify.sanitize(rawHtml, { USE_PROFILES: { html: true }, });

DOMPurify默认允许安全标签和属性，会把javascript:开头的链接、on事件属性这类危险代码剔除干净。我之前做过一次迁移项目，历史数据里的图片都是不安全的http链接，顺手写了一个正则统一替换为https，这种操作就是在v-html之前做的。

另外提一句，编辑器内部对内容的处理也是"宽松"的。大部分富文本编辑器语义化程度有限，会直接产出带大量内联样式的HTML，比如<p style="text-align: center;">。这些样式在编辑器内正常，复制到外部页面时可能和外层CSS冲突。所以内容展示和编辑器编辑，样式环境尽量一致，要么都引入同一份reset样式，要么展示时包一层专门的作用域class。很多前端会忘记把编辑器的样式文件引入到展示页面，结果编辑时一整排精美的排版，一到前台全变成了左对齐的纯文本裸奔。这一点务必要留意。

3.2 PDF打印场景：A4分页、样式隔离

热搜词里出现过"web页面pdf打印"，这个场景和富文本关系极大。很多业务系统需要把编辑好的文章直接打印成PDF或纸质文件。第一次尝试时你可能直接调用window.print()，发现内容挤作一团，或者分页把一段文字从中间劈开了。

富文本内容做PDF打印，至少要考虑三件事。

第一是CSS样式隔离。打印时浏览器默认会带上很多样式，我推荐用@page和@media print单独控制。对于富文本内容，最好给编辑器内容的外层容器加一个最大宽度，避免一行字太长影响打印效果：

@media print { .editor-content { width: 100%; max-width: 100%; padding: 0; } .editor-content * { -webkit-print-color-adjust: exact; print-color-adjust: exact; } .editor-content p, .editor-content h1, .editor-content h2, .editor-content h3, .editor-content blockquote { page-break-inside: avoid; } }

page-break-inside: avoid是最常用的技巧，可以防止标题、段落、图片在打印时被从中间截断。

第二是分页控制。如果内容是长文章，你可以在特定的块级元素上加page-break-after: always，实现类似Word里的手工分页。这在配置编辑器时可以预留一个"分页符"按钮，插入一个带特殊class的div，打印CSS里检测到它就强制换页。这个办法在多个项目里实测有效。

第三是字体和编码。有些Windows环境下的打印服务对中文支持不佳，会导致打印出来的PDF里汉字变成方块。我建议打印时显式设置字体为Microsoft YaHei或sans-serif，并且不要依赖编辑器里引用网页字体做打印。这个细节看似小，但打印场景翻车率极高。

3.3 资源受限的嵌入式网页：ESP32内嵌管理页该怎么做

看到热搜词里的"esp32内嵌web网页"，我有点惊讶，但也觉得合理——现在的嵌入式设备越来越多地提供Web管理页面了。ESP32这类MCU上跑一个轻量级Web服务器，资源非常有限，可能总共就几百KB的可用内存，这时候富文本编辑器的选型和配置就要彻底换一套思路。

你在ESP32上绝不可能跑起TinyMCE或CKEditor 5，甚至连wangEditor都显得太胖。常见的方案是使用极简的contenteditable实现，或者用非常轻量的编辑器，比如ribbon.js这类压缩后只有几KB的库。如果连库都不想引，直接手写一个contenteditable的div配合几个常用的工具按钮，反而最可控。

嵌入式场景下，富文本内容也不应该存HTML字符串。更好的做法是让编辑端输出纯文本或简单的Markdown，保存为数组结构或简化的BBCode风格标签，前端解析渲染，这样可以最大程度减少存储和带宽开销。在设计ESP32内嵌管理页时，我通常建议：

• 不使用大体积JS库，手动实现或者仅引入一个实用的工具库；
• 编辑器值只支持纯文本和换行，最多加一个加粗标记；
• 提交内容前做长度限制，防止用户输入过大内容撑爆MCU的内存；
• 内容展示时全部转义，杜绝XSS。

有的场景还需要在嵌入式设备生成的网页上把内容展示出来，同样要绕过编辑器，直接输出转义后的HTML。这背后的核心思路是：代码运行环境越弱小，功能就越要精简到刚性需求本身，这也是资源受限Web页面配置编辑器的基本准则。

4. 配置的安全边界：XSS过滤、上传鉴权与服务端合规

聊到安全，很多人第一反应是"编辑器里能打XSS？"，答案不只能，而且非常容易。富文本编辑器本身就是HTML注入的天然入口，从配置层面到服务端层面，安全都必须是贯穿始终的考虑项。

4.1 XSS过滤不能只靠编辑器

编辑器通常不会过滤掉所有可能危险的HTML。最典型的危险代码是<a href="javascript:alert(1)">点我</a>、<img src=x onerror=alert(1)>，以及各种伪协议的SVG事件。一些编辑器对链接的filter做得不错，例如CKEditor 5默认会在output的HTML里对href做一定清洗，但TinyMCE、Quill默认都不够严格。

我的实践经验是三层过滤：

1. 入库前用服务端库清洗一次，比如Java后端的jsoup，Python后端的bleach，Node后端的sanitize-html；
2. 展示前用DOMPurify再次清洗，双保险；
3. 配置编辑器本身，关闭危险功能。比如wangEditor可以配置editor.config.allowedLinkProtocols只允许http、https、mailto：

editor.config.allowedLinkProtocols = ['http', 'https', 'mailto'];

不要天真地认为内容都是内部员工输入的就不会出问题。我见过不止一次，内部系统的后台被测试工程师顺手粘贴了一段带事件属性的HTML，结果整个内网页面出现弹窗。安全问题和编辑器好不好用无关，永远要独立防御。

4.2 上传鉴权要配合服务端配置

上传接口如果只接受前端传来的任何文件，等于给攻击者开了个后门。常见的安全配置有：

• 校验Content-Type和文件后缀，而不是只依赖前端；
• 对上传文件做重命名，防止攻击者上传带特定标识的文件名；
• 使用对象存储的签名URL，而不是永远公开读写；
• 服务端限制文件大小，防止一个几百MB的文件直接拖垮存储。

在编辑器配置侧，customUpload里至少要有统一的鉴权Header和错误处理。拿前面那个fetch上传的例子来说，带上Authorization头是常识：

fetch('/api/upload/image', { method: 'POST', headers: { 'Authorization': `Bearer ${getToken()}`, }, body: formData })

Web服务器安全的很多原则在这里同样适用。所以说，富文本编辑器不是一个孤立组件，它天然与后端接口、存储策略、Web服务器安全配置绑定在一起。配置编辑器时，眼光要放开到整条链路。

5. 性能优化与配置项取舍：加载慢、内存高、编辑卡怎么破

富文本编辑器对首屏性能的拖累是有目共睹的。有时候一个页面上只为了填一段几十字的简介，却要加载一套几百KB的编辑器，明显不合理。

5.1 按需加载：编辑器不是首屏必需品

最容易优化的点就是延迟加载。很多后台页面进去之后根本不需要立即看到编辑器，用户在点击"编辑"按钮之前，编辑器可以完全不加载。现代前端框架的动态导入方案非常成熟，React的React.lazy和Vue的defineAsyncComponent都能实现这一点。

以Vue 3为例，把wangEditor包成懒加载的异步组件：

import { defineAsyncComponent } from 'vue'; const RichEditor = defineAsyncComponent(() => import('./RichEditor.vue'));

这样首屏不会引入编辑器的JS和CSS，用户真正使用时才加载，配合Loading动画，体感差距非常明显。

同一个页面如果有多处编辑器，比如一个可折叠表单里有三四个富文本区域，还有一个是要等待用户操作后才出现的，更需要做好懒加载。我遇到过最多的情况是页面一加载就把三四个编辑器全初始化了，结果首屏白白多跑了几百毫秒的JS。编辑器本质上是一个"用户交互到达时才需要的组件"，永远不要将它加入主进程初始化逻辑。

5.2 编辑卡顿：contenteditable的性能瓶颈与限制策略

输入卡顿是编辑器的根深蒂固问题。当内容里有大量图片、几十个表格以及很深的嵌套结构时，contenteditable的DOM操作会越来越慢，每次输入都可能触发大范围的重绘。这在配置层面缓解的办法有几个。

一是定期清理样式垃圾。很多编辑器会在粘贴外部内容时带上大量无意义的span和style，我会在onChange里定期调用以下逻辑过滤：

editor.config.onChange = (newHtml) => { // 过滤掉空span，合并相同样式 const cleanedHtml = cleanEmptySpans(newHtml); debouncedSave(cleanedHtml); };

二是设置合理的图片压缩策略。编辑器允许插入大图时，在上传环节做一次前端压缩，可以极大减少内容体积。canvas压缩是通用方案，但要注意CDN上缩略图的加载。

三是对编辑器的长度做限制。像微博那样限制140字不合适，但对绝大多数内容场景，限制在几万字以内完全够用，上方工具栏保留按钮的意义不大。很多产品对超长文本也没有刚需，限制长度其实是"配置层面的减负"。

5.3 轻量化配置是长期收益

最后想强调一下"配置量少"的价值。我们在第2节讨论了工具栏裁剪，这不仅是UI层面的简化，更是性能层面的优化——每个按钮背后都是一个模块，模块越多，加载和执行的JS越多。

如果项目里只需要标题、加粗、列表、链接这四个能力，我建议直接用Quill的snow主题配合最简工具栏，或者直接用wangEditor只保留对应菜单。在运行内存不宽裕的嵌入式设备上，甚至可以考虑完全绕过富文本编辑器，用几个按钮配合contenteditable的textarea实现。

资源受限场景有一种做法很实用：编辑器UI仍用富文本，但提交时只提取纯文本。这样既能保证用户的输入体验简单，服务端和数据库又不需要承载HTML的复杂度，兼具"所见即所得"和"存储极简"的优点。在ESP32内嵌管理页这类场景里，配置一个禁用格式化按钮的contenteditable区域，配合JavaScript自动转义，完全够用了。

6. 几个被忽视的配置细节：多语言、粘贴过滤与草稿保存

框架之外，还有一些经常被忽略的细节，单独拎出来讲一讲。

6.1 多语言与工具栏文案的统一

不少编辑器的默认语言是英文，切换多语言的方式各有不同。TinyMCE 6自带语言包插件，只要引入对应JS后设置language即可；CKEditor 5的语言包可以通过配置的方式引入。但这并不只是设置一个language字段那么简单——编辑器UI的翻译质量参差不齐，比如有些翻译生硬，用户会看到"列表"和"清单"混用。较好的做法是检查一遍官方语言包，如果不满意，可以在config里用自定义字典覆盖部分文案，但这会增加维护成本。我的建议是：做与目标用户语言一致的定制化UI，哪怕是少量按钮的文字定制，也比默认语言包更易用。

6.2 粘贴过滤：把Word里的脏样式挡在门外

用户从Word、WPS或网页里复制内容直接粘贴进编辑器，是常态化操作。默认情况下，编辑器会以HTML格式读取剪贴板，这意味着大量内联样式、废标签都会被带进来。结果就是编辑器看着碍眼，保存下来的HTML也是一团乱麻。

Quill 2.0提供了比较完善的正则匹配和clipboard模块处理方案，简单的做法是在初始化时配置粘贴处理器，把不需要的标签剥离掉：

const clipboard = quill.clipboard; clipboard.addMatcher('span', (node, delta) => { // 返回一个只有文本内容的delta，丢掉span样式 return delta.map(op => ({ insert: op.insert })); });

wangEditor的pasteHTML也可以自定义，TinyMCE还有paste_preprocess钩子：

tinymce.init({ paste_preprocess: (plugin, args) => { // args.content 是粘帖进来的HTML，在这里做清洗 args.content = args.content.replace(/<style[\s\S]*?<\/style>/gi, ''); } });

我强烈建议把粘贴过滤做成配置项的一部分，否则线上数据会很快变得无法维护——里面混杂着各种来源的样式标签，前端展示时怎么擦都擦不干净。这个环节做得好，后续内容的可维护性提升不止一个量级。

6.3 草稿保存与自动恢复

内容编辑器最大的噩梦是用户编辑了半天，一个误操作全部丢失。多数组件库提供了change事件，我建议在前端做一层草稿自动保存：每次onChange后，把内容写入localStorage或sessionStorage，并设置一个唯一的草稿key。用户下次打开编辑器时自动恢复。

具体实现上，加上debounce（防抖）很重要。编辑器内容大时onChange频率很高，直接同步到localStorage也不太合适。简单的方法是用setTimeout和clearTimeout控制：

editor.config.onChange = (newHtml) => { clearTimeout(saveTimer); saveTimer = setTimeout(() => { localStorage.setItem(draftKey, newHtml); }, 500); };

如果系统是登录态的，还可以把草稿保存到服务端，防止用户换设备。服务端草稿只需要一个接口接收内容字符串，本质上就是一个轻量级的"暂存"功能，配置成本低，体验提升显著。

7. 留给新手的实操经验清单

写完这些场景，最后汇总几条通用的实操原则，按优先级排列：

1. 选型决定上限：轻量场景硬上重型编辑器，后续再优化也有限；复杂交互需求选了轻量编辑器，后面会发现定制起来非常痛苦。多花一天时间在选型对比上，节省的是后面几周的排坑时间。
2. 编辑器配置的本质是"给业务做减法"：功能按钮不是越多越好，每一项配置都在增加体积、维护成本和误操作概率。保留刚需，删掉花哨，用户体验和代码质量反而都会更好。
3. 内容安全不能依赖编辑器：入库前、展示前、编辑器内三个环节都要做过滤，这是Web安全的基本功。
4. 性能优化从"延迟"入手：编辑器永远不会是首屏的核心内容，延迟加载能解决大部分的性能焦虑。体积优化、配置项削减只是在延迟加载基础上的进一步增益。
5. 打印与展示是富文本的"第二场景"：不要在展示和打印时才手忙脚乱地调CSS，写编辑器配置时就考虑好内容的输出环境和样式约束，会给下游开发省很多事。
6. 草稿保存不是可选项：即使只是单机工具，也建议做本地草稿。用户损失一次编辑内容，对整个项目的信任感都会大打折扣。

回到文章开头那句话，富文本编辑器远不是一个开箱即用的组件。它在不同Web场景下的应用差异，比你想象中大得多——后台CMS、长文档编辑、资源受限的嵌入式管理页、打印导出场景，每一种都需要不一样的配置策略和取舍思路。希望这篇基于实际项目经验的总结，能帮你在下一次接到"页面里加个富文本编辑器"的需求时，少走一些我走过的弯路。