基于CKEditor 5的汽车工艺文档在线编辑与Word导出方案

上周有个搞汽车零部件的老哥找我，说他们准备上一套工艺文件在线编制平台，问我在线编辑器用哪个比较省事。我第一反应是这需求听着不难，无非就是个富文本编辑器嘛。结果他给我发了他们现用的工艺卡模板，我当场就不吭声了——一张工艺卡里，有CAD导出的装配示意图、形位公差标注、加工参数计算公式、BOM表格，还有一堆质检数据。这些东西放在本地Office里都够折腾的，要搬到浏览器里在线编辑，再原样转成Word发给主机厂评审，这已经不是“选个富文本”能解决的事了。我最后给他的建议里，CKEditor是绕不开的核心，而且真正难做的其实是CAD图纸和公式这两类特殊内容的“转存链路”。

这篇文章就把这套方案的完整思路拆开讲。内容适合三类人看：一是给制造业或汽车行业做Web文档系统的工程师，二是正在选型在线编辑器的产品经理或IT负责人，三是在技术方案里被“图纸、公式、Word导出”三个需求同时夹击的开发同学。我尽量不堆概念，直接说选了什么、为什么这么选、落地时踩了哪些坑。

1. 汽车企业的文档流转，卡在“图纸+公式”这道坎上

制造业做文档和互联网公司做文档完全是两码事。互联网公司写个Markdown，导出PDF收工。汽车制造企业不行，他们的技术文档是“工艺卡”“检验基准书”“设计变更通知单”这类东西，每份文档的构成都极其复杂。我自己给几家零部件供应商做过类似系统，有一个很直观的判断：凡是文档里同时出现CAD图纸和数学公式的场景，市面上九成在线编辑器都搞不定。

1.1 一张工艺卡里到底装了多少种内容

咱们把一张典型的汽车工艺卡拆开看，就知道为什么需求这么折腾。

第一类是常规文本，比如工序名称、设备编号、操作描述，这部分任何编辑器都能搞定。第二类是CAD图纸，也就是零件图、装配图、夹具示意图。图纸不是简单插个图片就行，它可能有多个视图，有尺寸标注、公差标注、表面粗糙度符号，主机厂审核的人要放大看细节。第三类是公式，比如切削速度计算公式、扭矩计算公式、SPC控制图的上下限公式，这些公式在Word里是用MathType或Word自带公式编辑器插进去的，要求导出后还能二次编辑。第四类是表格，BOM表、检测记录表，表格里还有合并单元格、斜线表头、跨页重复标题行这些复杂要求。

这四类内容混在同一份文档里，每个都有自己的一套技术栈，合在一起就是一个复杂的工程问题。Web端在线编辑器能处理第一类和第四类，第三类勉强可以做，第二类才是真正劝退大多数方案的门槛。

1.2 老流程的三大痛点：版本混乱、协作低效、格式失控

在没有在线编辑系统之前，零部件的工艺文档流转基本靠“本地Office+邮件/网盘”推进。流程是：工艺员在本地画好图纸（CAD），调好公式（MathType），写好工艺描述，保存成Word，然后发出去。听上去没什么问题，实际上全是问题。

版本混乱是最头疼的。一份工艺卡，三个人各改一版，最后汇总的时候根本分不清哪个是最新的。主机厂客户在审核时提出修改意见，工艺员改了一处尺寸标注，但忘了同步更新对应工序的公式参数，这种低级错误在邮件往来流程里几乎无法避免。

协作效率低也很明显。一个工艺团队十几个人，图纸存放位置、命名方式各有一套习惯，找一份最新的零件图经常要打好几个电话。加上很多企业的图纸是DWG格式，非设计人员根本打不开，或者打开后缺字体、缺外部参照，显示得乱七八糟。

格式失控则让最后的汇总裁决变得极其痛苦。同一套模板，有人用Office 2010，有人用Office 2019，还有人用WPS，排出来的版式千奇百怪。图纸在A电脑上正常，换到B电脑就出现字体错乱甚至图形丢失。到了提交节点上，IT部门只能一遍遍帮人调整格式，变成一个纯粹的体力活。

所以很多企业意识到，必须有一个统一的Web平台，所有人用同一套标准在线填工艺卡，图纸和公式都由平台统一转换和存储，最终导出格式可控的Word。这个思路没有问题，真正的问题在于执行层——在线编辑器能不能扛起这种复杂度。

2. 为什么选CKEditor 5：它解决了“编辑器不可能三角”

市面上的富文本编辑器不少，Quill、TinyMCE、wangEditor、CKEditor，我基本都上手试过。在汽车制造这个场景里，选型不能只看“能不能加粗、能不能插表格”，要看三件事：扩展性、数据可控性、导出兼容性。

我给这个需求总结了一个词，叫“编辑器不可能三角”——大多数开源编辑器只能满足“界面好”、“扩展容易”、“导出规整”中的两个，第三个总得牺牲掉。Quill界面简洁，扩展插件体系也算成熟，但它自己的数据模型是Delta格式，存储和还原都要走JSON，导出Word时还要手动把Delta解析成DOM或docx结构，等于多了一层转换。TinyMCE功能全面，传统的DOM编辑模型让它很灵活，但插件生态虽大，针对CAD交互、MathType集成这类工业场景的能力并不突出，自定义插件的写法和调试成本也不低。

CKEditor 5之所以最后胜出，不是因为它某个单项最强，而是它把“架构”这件事做对了。它本质是一个基于模型-视图-控制器架构的框架，插件机制是头等公民，编辑器实例就是由一堆插件组合出来的。这意味着，CAD图纸和公式这两个特殊需求，都可以通过写自定义插件的方式，融入编辑器主流程，而不是像在其他编辑器里那样靠“hack”来实现。

我把几个候选方案的关键差异整理了一下，方便你看得直观：

选型其实就是在回答一个问题：你愿意为“特殊对象”的编辑和导出写多少代码。在CKEditor 5里，插入一张CAD图纸可以是一个独立的编辑器组件，插入一个公式可以是MathML数据的可视化展示，它们在编辑器里有着自己的行为和渲染方式，但进入文档数据模型后又能统一管理。这让后面的转存流程轻松很多。

2.1 对比了一圈，CKEditor 5的优势到底在哪儿

不用夸得天花乱坠，我就说三个实测下来最有价值的点。

第一，自定义插件的设计是“正经”的。CKEditor 5把编辑器内部实现分为模型层和视图层，自定义一个元素时，你定义它在模型里的语义、在视图里的渲染、以及用户怎么通过命令去操作它。这种设计和工程规范接轨，适合多人协作开发。比如我要做一个“CADDrawing”元素，它可以像图片一样拥有src属性，但数据结构上可以额外挂一个drawingId来对应后端的DWG文件编号，后期做版本追溯就方便了。相比在Quill里自己写Blot，这种方式少了大量手忙脚乱的状态同步。

第二，它在无障碍、快捷键、浏览器兼容这些基础体验上投入很大，这些对工业用户很重要。工厂里的工程师不少还在用Windows 7上的老Chrome或Edge，界面上按钮要大，操作要直接。CKEditor 5的UI组件和快捷键体系比很多编辑器完整，实测在这些老内核浏览器上基本不出幺蛾子。

第三，它的数据输出是可预测的HTML结构。这一点对导出Word极其关键。因为docx本质上是一套基于XML的文档格式，HTML到docx的映射，结构越规整，转换越轻松。CKEditor 5产出的HTML不像传统编辑器那么“脏”，它有一套自己的视图规则，生成的标签整洁、嵌套清晰，这种可控性在自动化处理时就是效率。

2.2 方案总览：CAD图纸、公式、Word导出如何协同

文章讲到这里，可以先把整体架构说清楚，后面每个模块再展开。

我推荐的是一个前后端协同的方案：前端负责CKEditor 5的集成、CAD图纸SVG化展示、公式的MathML编辑和渲染；后端负责DWG到SVG的转换、Word文档的最终生成和下载。数据流大概是这个走向：

浏览器里，用户点击工具栏上的“插入CAD图”按钮，前端把选中的DWG文件编号发给后端，后端调用转换服务把DWG文件转换成SVG（同时生成一张高分辨率PNG作为导出备用图），前端拿到SVG后，把这个图作为CKEditor里的自定义元素插入文档。用户点“插入公式”时，MathType插件弹出公式编辑窗口，用户编辑完成后，公式以MathML格式嵌入文档。整份文档在编辑器里就是一个带自定义元素和MathML标签的HTML。

点击“导出Word”时，前端把编辑器的HTML结构解析成中间JSON，通过接口交给后端。后端拿到JSON后，用docx生成技术栈构造Word文档：CAD图纸用高分辨率PNG嵌入，公式用MathML转换OMML（Word原生公式格式），表格转成Word表格对象，最终生成docx返回给用户下载。

这个架构看起来复杂，但好处是前端只负责编辑和展示，最终的出版级转换交给后端处理。企业里对Word的模版要求很高，比如页眉必须带公司logo、字体必须宋体小四、行距必须固定值，这些用前端库硬拼效率很低，后端处理就从容得多。

3. 核心实现：让CAD图纸和公式真正“进得来、出得去”

光说概念没有用，我拿具体实现来讲。这一章是整篇的干货区，CAD图纸、公式、Word导出三个子任务分别拆解，每一段都是可以直接落地的做法。

3.1 CAD图纸：从DWG到Web可预览，再嵌入到编辑器

CAD图纸在车间里的格式几乎全是DWG，浏览器本身不支持DWG格式，所以第一步要做格式转换。这个环节最容易犯的错误是“输出一张JPG就完事”，那样图纸放大就糊了，尺寸标注也看不清，完全没法用于审查。

我的做法是：后端维护一个转换服务，用AutoCAD或中望CAD的批处理命令，把DWG导成SVG和PNG两种格式。SVG用于在编辑器里显示，因为它是矢量图，缩放清晰；PNG要导成至少300DPI的高分辨率版本，用于最终Word嵌入。之所以要用PNG而不是SVG嵌入Word，是因为Word对SVG的支持不稳定，尤其是老版本Office，插入SVG后可能出现空白或显示异常。高分辨率PNG兼容性最好，打印也清楚。

转换完成后，前端通过CKEditor 5的自定义插件，把SVG图片嵌进编辑器。这里要注意，直接把SVG作为img的src插入是可以工作的，但更好的办法是定义成一个独立组件。我写过一个简化的自定义插件，核心逻辑是这样的：

import { Plugin } from '@ckeditor/ckeditor5-core'; class CadDrawing extends Plugin { static get requires() { return [ 'Image', 'Widget' ]; } init() { const editor = this.editor; editor.model.schema.register( 'cadDrawing', { inheritAllFrom: 'image', allowAttributes: [ 'drawingId', 'dwgName', 'svgUrl', 'pngUrl' ] } ); editor.model.schema.extend( 'cadDrawing', { allowIn: [ 'image' ] } ); editor.commands.add( 'insertCadDrawing', { execute: ( attributes ) => { editor.model.change( writer => { const cadElement = writer.createElement( 'cadDrawing', { drawingId: attributes.drawingId, dwgName: attributes.dwgName, svgUrl: attributes.svgUrl, pngUrl: attributes.pngUrl } ); editor.model.insertContent( cadElement ); } ); } } ); } }

这样设计的好处是，图纸不再是“一张普通的图片”，它带着dwgName和drawingId这些元数据。你可以针对这个元素实现右键菜单，比如“打开原图”“查看变更记录”“关联工序”，在编辑体验上完全是定制化的，而不是让用户把DWG当图片插进来。

插入后，还需要让用户能选中、拖动、调整大小。CKEditor 5的Widget和Image组件提供了现成的支持，把自定义元素注册为Widget，就会获得和普通图片一致的选中和缩放操作，这一点很省事。

3.2 公式编辑：MathType接入与MathML数据流

公式部分我直接用MathType官方提供的CKEditor 5插件。汽车企业的工艺文档里大量公式是用户拿MathType在Word里写的，企业内部的数据标准也认MathML格式，所以选择MathType可以保证和用户端工具链一致。

集成很直接，安装依赖后注册插件即可：

import MathType from '@wiris/mathtype-ckeditor5'; import '!raw-loader!@wiris/mathtype-ckeditor5/src/plugin.css'; ClassicEditor.create( document.querySelector( '#editor' ), { plugins: [ MathType, ... ], toolbar: [ 'MathType', 'ChemType', ... ] } );

用户在编辑器里点MathType按钮，弹出的窗口和Word里用MathType几乎一样，编辑完关闭，公式就以MathML的形式插入到文档里。同时MathType插件会负责把MathML渲染成可读的公式样式，所以编辑时看起来没问题。

但这里有一个关键点很多人会忽略：公式在页面里的显示由MathType处理，但最终转存Word时，MathML不能直接塞进docx。Word能识别的是OMML格式，也就是Office Math Markup Language。所以导出的核心工作之一就是做MathML到OMML的转换。微软官方有一套XSLT转换脚本（在Office安装目录里能找到MML2OMML.XSL），可以处理后端Java环境下的转换。

如果不用MathType，还有一种纯前端思路是集成MathJax或KaTeX做公式渲染，保存时用MathML，导出时在Java后端做XSLT转换。这个方案也可以，但MathType的优势在于厂商已经把所有交互细节都处理好了，包括键盘输入、符号面板、兼容性，工业环境里越少自己造轮子越好。

公式转存时还要注意一个问题：如果后端转换失败，要有一个兜底策略。我建议不要直接报错，而是把这个公式降级成高清图片放入Word，同时在Word批注或文档属性里标注公式ID，方便用户在Web平台上重新编辑。这个兜底对大批量文档处理非常重要，因为一份工艺卡里可能有几十个公式，一个转换失败导致整份文档导不出来，用户体验是毁灭性的。

3.3 Word导出：HTML编辑器内容如何转换为规范的docx

Word导出是整个流程里最容易出问题也最考验工程能力的环节。思路其实很清晰：前端的CKEditor把HTML内容整理成结构化的JSON，交给后端，后端把它拼装成docx。为什么要绕后端，而不是前端直接用docx.js这样的库生成？因为企业级Word文档有严格的模板要求——页眉页脚、字体字号、行距、段落缩进、编号样式，这些在前端生成时非常吃力，后端处理则顺理成章。

我验证下来，最稳的路子是后端Java配合docx4j或Aspose.Words。Aspose.Words对复杂排版支持更好，但商业授权费用高；如果预算有限，docx4j也可以，但处理复杂表格时要多写不少代码。这里的具体选型要根据项目预算和技术栈来定，我给一个通用的拼装逻辑：

后端接收的JSON包含段落、表格、图片、公式四种类型的节点。遍历节点时：

• 普通段落直接映射为docx的Paragraph，设置好字体、字号、行距。
• 表格节点转换成docx的Table，要特别处理合并单元格和列宽——从CKEditor的HTML表格结构里解析colspan、rowspan，再映射到docx的gridSpan、vMerge。
• CAD图纸节点使用高分辨率PNG，通过ImageRun嵌入，宽度按页面可用宽度等比缩放。图纸下方加一行图注，写上图号和图名。
• 公式节点把MathML转换成OMML，用docx的oMath标签包裹。这样生成的公式在Word里是可编辑的原生公式，用户还能继续改，这是甲方最喜欢的效果。

实际开发时，如果有能力，可以再用POI-TL这类模板引擎来做循环填充。它的思路是先在Word里做一个模板，利用占位符标记位置，程序运行时填入数据。对固定的工艺卡模板来说，POI-TL能省掉大量手工创建段落和表格的代码，非常推荐。

4. 落地过程中最折磨人的几个坑（附完整排查链路）

方案设计看着美好，真正落地时遇到的坑能把人磨死。这一章我挑四个最有代表性的，每条都给出完整的排查链路，不是直接甩结果，而是告诉你我是怎么一步步定位的。

4.1 坑一：SVG图纸导出的Word里显示空白

这个坑是我第一次联调时遇到的。CAD图纸在编辑器里显示完全正常，结果导出的Word文档里大片空白，偶尔有一个小叉子图标。我一开始怀疑是后端图片拼接的问题，就去看后端日志，把生成的docx解压出来，发现媒体文件夹里确实有PNG文件，但图片尺寸是0x0。

继续往上追，发现是图片流的问题。我们插入CAD图纸时候，编辑器里的SVG是带一个viewBox属性来定义坐标系的，转换PNG时为了图方便用了简单库，结果它读不到viewBox信息，生成了一个宽高为0的图片。这个问题的根因是：SVG的width和height属性为空，缩放信息全在viewBox里，而部分转换库不支持viewBox解析。

解决方式是，在DWG转SVG时，显式地在SVG根节点上写好width和height属性，和viewBox保持一致。同时，插入编辑器时读取SVG的宽高，作为自定义元素的默认宽高。做了这两步之后，导出的PNG宽度高度就正常了。

这个坑给我们的教训是：前端展示用SVG可以，但它只是“预览载体”，最终的打印和出版必须走高清PNG，而且所有元信息要提前在转换阶段固化下来，不能依赖前端实时计算。

4.2 坑二：MathML转换成OMML后，Word打开报错“公式域损坏”

MathML到OMML的转换，官方XSLT脚本确实能用，但在复杂公式上翻过车。最典型的是一次包含分数、上下标、根号的大公式，转换出来的OMML结构不闭合，Word打开时直接提示“此文档中的公式可能已损坏”。

排查那天特别耗时间。我把出问题的MathML和转换后的OMML逐行对比，发现分数的分子部分里嵌套了另一个分数，而XSLT模板在处理嵌套结构时，生成的m:f元素嵌套层级和Word要求的不一致，导致XML结构不合法。

解决思路有两条。第一条是加固XSLT转换脚本，写一个后处理环节，用XML解析器对生成的OMML做一次校验，检测元素是否闭合、父子关系是否合法。第二条是换一个更成熟的转换库，比如商业库或者MathType官方提供的服务端SDK，它对各种边界情况处理得更完善。

我的建议是，如果公式复杂度不高，官方XSLT够用，但必须加一层校验。如果公式复杂度高，老老实实上商业方案，不要在这上面省成本——公式损坏在汽车行业文档里是重大质量问题。

4.3 坑三：编辑器里的图片导出到Word时，全部带着blob前缀

这个坑比较隐蔽。我在一台测试机上把Word导出功能跑通了，但第二天换了一台机器上测试，导出的Word里所有图片都无法显示。后端日志里记录的图片地址是blob:http://localhost:8080/xxx这样的前缀，明显是浏览器的临时对象URL，后端根本访问不到。

排查过程是这样的：先怀疑是前端上传组件的问题，后来发现CKEditor在处理图片时，有一种方式是直接把图片作为base64数据内嵌在HTML里，另一种是给图片一个blob URL。由于我的自定义插件在插入CAD图纸时使用的是后端返回的正式URL，所以CAD图纸没问题，问题出在用户手动粘贴的普通图片上——粘贴时浏览器会在内存里生成blob URL，而CKEditor默认配置允许这种URL进到文档模型里。

解决方法是，在CKEditor的文件上传和图片处理配置里，拦截所有以blob开头的src，把它们统一转成base64数据，或者在粘贴时立即触发上传接口，把blob URL替换成服务端URL。我在项目里选择了“粘贴即上传”的方案：用户粘贴的图片自动传到文件服务，返回正式URL后替换掉blob。这一招对后来的多人编辑功能也有好处，因为blob URL只在单个浏览器会话里有效，其他人根本看不到图。

4.4 坑四：大图纸序列化后，编辑器卡死

工艺卡里如果插入一张几兆的SVG图纸，浏览器标签页基本就成了幻灯片。这个问题出现在我们第一次做真实车间数据测试时，用户的图纸有复杂的剖面线、大量标注，SVG文件有两三兆，编辑器从插入到选择，每一步都有明显的卡顿。

一开始怀疑是SVG本身太大，转成PNG放大后也会有性能问题。后来用Chrome的性能分析工具一看，发现卡顿的根源不是图片渲染，而是CKEditor的模型层在做序列化时，把SVG里的所有文本节点都当成文档内容处理了——SVG本质是XML，里面每一条尺寸标注文字、图例文字，都成了编辑器模型里的文本节点，于是编辑器的撤销历史栈被撑爆了。

解决思路是，不能把SVG当作可编辑文本插入，必须把它当作一个整体对象。我在自定义插件里调整了策略：编辑器里显示的是SVG预览，但核心内容是用一个自定义元素承载的，它的内部文本被标记为不可编辑，编辑器的模型里只保存这个元素的引用和展示属性，SVG本身完全放在DOM的shadow realm里，不进文档模型。

改造完之后，编辑器的操作流畅度立刻上来了。这个经验很受用：在富文本中嵌入外部复杂对象时，一定要明确对象边界，不要让编辑器去管理外部格式的内部细节。

5. 上线前还要考虑的性能、安全和运维问题

系统功能开发完，不等于能上线。制造企业的IT环境比互联网公司要复杂，很多细节不注意，上线第一天就会被车间工人的电脑教育一顿。

5.1 浏览器兼容和低配电脑适配

车间里的电脑，配置普遍不高，很多还是机械硬盘加4GB内存，浏览器版本停留在Chrome 80甚至更老的Edge。CKEditor 5对现代浏览器支持很好，但低配机器上打开带大图纸的文档时，要特别注意内存占用。

我的建议是：给编辑器加上“性能模式”，在文档里图片数量或大文件数量超过阈值时，自动用懒加载方式渲染，只有滚动到可视区域时才加载图纸。同时，编辑历史保存操作尽量节流，控制在每秒最多一次，避免频繁触发大快照。

对老浏览器的兼容，最好在选型阶段就定好目标浏览器列表，建议至少覆盖Chrome 80+、Edge 80+和火狐78+。如果还要兼容IE11……那就做好从CKEditor 5换回CKEditor 4的心理准备，CKEditor 4虽然有维护模式，但老归老，至少能在老浏览器里稳定跑。

5.2 文档存储、权限与版本管理

Web编辑器解决的不只是“录入”，更是“流转”。文档数据建议不要只存HTML，而是存一个JSON结构：包含HTML正文、图纸引用列表、公式列表、模板版本号。这样后续做差异对比和变更追踪会很方便。

汽车行业的文档都有严格的签审流程。图纸从DWG到SVG再到PNG，每一版变更都要留痕。在编辑器里，CAD图纸元素上挂着的drawingId会和后端的图纸版本表关联，用户在编辑器里看到的是“当前有效版本”，但历史版本始终可以追溯。公式也一样，MathML里可以附带公式的版本编号，方便同行评审时对比修改了什么。

权限控制方面，建议在编辑器外层做，而不是依赖编辑器自身。CKEditor 5有只读模式和编辑模式的切换，文档在审批状态下自动进入只读，签审后才能回到编辑。这样可以保证在线编辑不会和审批流程打架。

5.3 导出服务的容错与重试

Excel和Word这类导出任务，在高并发或大文档场景下不适合用同步接口等待。建议把导出做成异步任务：前端点击导出后，后端创建任务，轮询查询状态，完成后返回下载链接。

异步化之后，任务队列、失败重试、超时控制就有必要了。我实测下来，一份包含20张图纸、50个公式的工艺卡，转Word在一次完整的转换流程里约需要3到5秒，这还是在不考虑高并发的情况下。如果企业有几十个人同时导出，同步接口的响应时间会飙升到不可接受。

异步任务还要设计一个合理的重试策略。比如图纸转换服务可能临时不可用，任务失败后自动重试三次，每次间隔5秒、10秒、30秒。如果三次都失败，就给用户明确的失败原因，而不是让用户干等。

5.4 监控和日志：知道用户卡在哪一步

制造企业的IT团队，往往对用户操作的可观测性重视不够。等用户报告“导出Word打不开”的时候，你才发现根本不知道用户是用什么模板导出的、在哪一步转换失败了。上线前一定要做两件事：一是业务日志，记录每次导出任务的耗时、图纸转换数量、公式转换数量、失败节点；二是埋点，记录用户在编辑器里插入图纸和公式的平均耗时，如果某个操作耗时超过500毫秒，就要考虑是不是需要重做缓存。

这些数据看似小事，但对系统的持续优化价值巨大。我做第一版系统时，没有埋点，结果客户反馈“编辑器越用越卡”，我远程排查了三天，最后发现是某台PC的浏览器扩展和CKEditor冲突，导致每次打开文档都要反复重新渲染。如果一开始有完整的错误采集，这个问题的定位可能只需要十分钟。

最后说点实际的

做了几个制造业文档系统之后，我的体会是，这类项目真正的难点从来不在富文本本身，而在于“围绕富文本搭建的整个生态”。CKEditor 5只是一个容器，你用什么样的插件来承载图纸、公式、表格，用什么方式来生成Word，怎么处理用户环境中千奇百怪的浏览器和Office版本，这些才是真正的分水岭。

如果你正在评估类似方案，我的建议是：第一，不要在编辑器选型上反复纠结，CKEditor 5已经是很稳的选择，重点投入应放在自定义插件和导出服务上；第二，CAD图纸的转换链路一定要走高质量数据，SVG只做预览，PNG做出版，中间的统一数据模型是图纸ID，这样才能支撑后续的版本管理；第三，公式处理一定要在选型阶段就确认好MathML到OMML的转换方案，不要等开发到一半再去填坑。

最后再分享一个小技巧，CKEitor 5在自定义插件里如果想调试数据模型，可以直接在浏览器控制台打印editor.getData()的返回结果，它比直接看页面DOM要直观得多。很多排版和嵌套的怪问题，看这个输出比在DOM里瞎猜效率高一个数量级。