做在线教育平台这两年我见过最多、也最让人头疼的操作就是“从 Word 里复制题目到编辑器再保存发布”。运营和教研上传的讲义、试卷里大量数学公式从 Word 粘贴到百度编辑器后表面上看着是正常文字一预览就卡死有的甚至整个页面白屏。问题听起来像个简单的粘贴兼容性坑但真把公式量堆起来——比如一份试卷里塞了三十道带根号、分式、矩阵的题——你会慢慢发现瓶颈其实不在编辑器本身而在公式内容的整套渲染链条。作为负责这块前端基础设施的人我前后花了不少时间把这条链路的每个环节拆开看了一遍剪贴板的格式处理、编辑器内容清洗、页面端公式渲染、缓存策略、后端存储格式。这篇文章会把整个优化方案、核心代码思路、踩过的坑和最终实测效果一次性整理出来。适合正在维护教育类网站、题库系统或内容管理平台的开发者参考就算你没用过百度编辑器里面关于公式内容清洗和按需渲染的思路换到其他富文本编辑器上也一样能落地。1. 先把问题定位准Word 公式进入编辑器后到底发生了什么1.1 一个公式为什么能让整个页面卡住先说一个最反直觉的现象一个只有几十个字符的数学公式复制到编辑器里产生的 HTML 代码量可能超过几千字节甚至上万字节。因为 Word 的公式并不是普通文本底层用的是 OMMLOffice Open XML Math Markup这是一套嵌套很深的 XML 标记语言。你从 Word 复制公式时剪贴板里带过来的不是干净的公式文本而是一整棵复杂的 XML 树里面包含了分式、上下标、根号、矩阵、括号配对等大量结构信息。这些内容粘贴到百度编辑器后编辑器的处理逻辑是把剪贴板里的 HTML 片段直接做过滤、清理然后通过 innerHTML 塞进编辑区域。麻烦就在这一步UEditor 默认是针对普通文本和简单排版设计的对公式这种“XML 末端的怪物”没有专门优化路径。它会把 OMML 当作普通 HTML 标签处理该清理的样式没清干净不该保留的命名空间却原样保留一套公式几十个嵌套标签堆在 DOM 树里每一个外层标签的渲染还会触发浏览器重新计算布局和样式。低端机或者浏览器版本稍旧的环境下公式一多输入光标移动都会变成“一步一卡”。更麻烦的是很多教育平台后面还接了公式渲染引擎比如 MathJax、KaTeX。编辑器里存的是 Word 原始标记发布后又要让渲染引擎从这套标记里再解析一遍。等于同一份公式用户操作时被浏览器硬算一次页面展示时被渲染引擎再算一次。两条计算路径叠加页面不慢才怪。1.2 真正拖慢页面的三个环节缺一不可我把整个过程拆成了三段看逐段定位损耗第一个环节是剪贴板格式处理。Word 附带过来的 OMML 节点和大量mso-开头的内联样式如果没有在编辑器入口处拦截并清洗这些冗余内容会成为页面解析的首要负担。这一步如果做得好能省掉后续至少一半的 DOM 节点数量。第二个环节是存储内容和展示逻辑不对齐。如果数据库里存的还是 Word 的 OMML 标记那每次页面渲染前端渲染引擎都要重新把 OMML 当“维修说明书”来读一遍再换算成可视公式。这个过程既耗 CPU 又耗带宽。要知道一份带公式的试卷或讲义内容里可能有一两百个公式全是这种深层嵌套结构传输和解析的开销不是线性增长而是近似于指数级增长。第三个环节才是渲染引擎本身。MathJax 有两个耗性能的短板一是全文档扫描模式页面初始化时会把整个文档里所有公式一次性排版二是渲染过程中的字体和布局计算很重公式越多主线程就会被长时间占用。很多页面白屏、卡顿其实不是公式多而是渲染引擎在初始化阶段就把主线程占满了用户只能干等。把这三个环节梳理清楚之后优化目标就变得很明确在入口做减法在存储做转换在渲染做按需。2. 整体方案设计从“一次性全量渲染”改成“两段式按需渲染”2.1 方案选型背后的取舍逻辑一开始团队里有两种优化思路。一种是在前端把 MathJax 的配置调优比如延迟渲染、分批排版、禁用自动扫描动刀不大见效也快。但实际压测时发现公式量一旦超过 80 个MathJax 即使开了分批渲染首屏可交互时间还是压不下来。原因在于 MathJax 走的是“整页排版”模型它需要维护一套公式布局引擎分式的横线、根号拐角、矩阵的对齐全部要在计算后才能放到页面里天然吃资源。另一种更彻底也是我最终选择的路线先从源头把数据改轻。编辑器粘贴时将 Word 带来的 OMML 转换成更标准、更轻量的 MathML 或 LaTeX 标记数据库里统一存转换后的轻量标记不再让 OMML 裸奔到前端页面渲染时接入 KaTeX 这类体积更小、同时同步渲染速度更快的引擎并用 IntersectionObserver 做视口按需渲染只有公式真正进入可视区域才计算其他公式先占位不渲染。这个方案的核心思路我把它归纳成一句话能清的在入口清掉能转的在存储层转完能缓存的在浏览器端缓存渲染这件事千万不要一口气全部做完。2.2 完整链路长什么样优化后一份从 Word 复制到备课栏的公式最终走的是这样一条链路粘贴触发 → 监听 paste 事件 → 识别 Word 公式特征 → 提取 OMML 结构 → 清洗无用的 Word 样式 → 递归遍历结构、转换为轻量公式标记 → 插入编辑器 → 保存到数据库 → 页面发布时前端扫描公式节点 → 视口内的公式统一交给 KaTeX 渲染 → 渲染结果缓存到本地 → 后续滚动到其他公式时继续触发渲染队列。链路看起来长但因为每一步都是轻处理实际用户感知很快。尤其把 OMML 清洗和转换放到编辑阶段后端存储内容干净了前端渲染引擎的工作量也就降下来了。优化这件事越靠近源头效果越明显。2.3 为什么不干脆全面换成图片或 SVG还有人提议公式不渲染直接转成图片彻底绕开所有文本渲染问题。这个方案我在早期也试过发现有三个致命缺点图片不可检索、不可复制、不可二次编辑。教育场景里学生做题后经常要复制题目里的公式去搜索引擎查解法或者老师要在一份旧试卷基础上改几道公式题重新出卷。一旦公式变成静态图内容编辑的灵活性就被锁死了。所以我坚持保留文本化的轻量标记只优化渲染方式不牺牲内容本身的可用性。3. 关键实现细节拦截、清洗、转换与渲染的落地过程3.1 第一步粘贴事件里识别 Word 公式要让公式走自定义处理流程得先让编辑器认出什么是 Word 公式。百度编辑器提供了beforepaste事件可以在默认粘贴逻辑执行前拦截剪贴板数据。Word 公式在 HTML 片段里有两个非常明显的特征一个是带m:oMath标签另一个是一堆xmlns:m.../officeDocument/2006/math的命名空间声明。代码可以这样判断editor.addListener(beforepaste, function (e, arg) { var clipboard arg.clipboardData || window.clipboardData; if (!clipboard) return; var html clipboard.getData(text/html) || ; var hasWordMath /m:oMath/i.test(html); var hasMathXml /xmlns:m[^]*officeDocument\/2006\/math/i.test(html); if (hasWordMath || hasMathXml) { arg._isWordFormula true; } });这里有个小细节不同 Word 版本复制出来的 HTML 片段存在差异有些新版 Word 粘贴时不一定带上完整的m:oMath标签但会带有m:oMathPara或者大量mso-前缀样式。所以稳妥的做法是三个特征同时检测满足任意一个就先走公式处理逻辑。宁可多识别一次也不要漏识别。3.2 第二步把 OMML 从混杂 HTML 里安全剥离粘贴过来的内容里OMML 通常混在一堆 Word 样式的 span、font、p 标签中间。清洗的原则是先剥壳再取核。不要一上来就对整个 HTML 做正则替换那样容易把公式内部的结构标签误伤掉。正确做法是先解析 XML把m:oMath节点整体提取出来再单独处理这些节点内部的标签。function extractWordMath(html) { var parser new DOMParser(); var doc parser.parseFromString(html, text/xml); var mathNodes doc.getElementsByTagName(m:oMath); var results []; for (var i 0; i mathNodes.length; i) { results.push(mathNodes[i]); } // 如果没有找到标准 m:oMath尝试带命名空间的兜底获取 if (results.length 0) { var ns http://schemas.openxmlformats.org/officeDocument/2006/math; mathNodes doc.getElementsByTagNameNS(ns, oMath); for (var j 0; j mathNodes.length; j) { results.push(mathNodes[j]); } } return results; }用 XML 解析而不是字符串截取原因在于 OMML 里标签是严格嵌套的正则拆字符串很容易因为分式中嵌套了另一个分式而直接把结构拆错。解析成 XML 树之后每个节点的父子关系清清楚楚后面做递归转换就顺了。3.3 第三步清洗 Word 附加样式保留公式骨相公式节点提取出来后还不能直接塞进编辑器。OMML 内部还挂了一堆mso-开头的内联样式、空的span、无意义的w:rPr字体属性标记。这些对公式显示没有帮助只增加 DOM 体积。清洗时按以下优先级处理删掉所有style属性里mso-开头的样式声明删掉空的span和font标签但保留其中的文本内容删掉w:rPr、w:rFonts这类 Word 专有的格式节点保留所有m:*开头的数学结构标签一个都不能删。这里特别提醒一下清洗千万别用简单的stripHtml操作比如textContent直接取值那会把分式、矩阵、上下标的层级结构全部拍扁。清洗的正确姿势是逐节点判断有选择的递归清理不是一刀切。3.4 第四步OMML 转换到轻量标记这是整个方案里工作量最大的一步。OMML 是 Word 私有格式Web 端没法直接渲染得转成 MathML 或 LaTeX。两种目标各有利弊MathML 保留了最完整的结构信息但体积较大LaTeX 表达紧凑、存储友好但解析规则更复杂容易出错。我最后选了 MathML 做中间态再在需要时从 MathML 转 LaTeX。原因是教育平台后续可能对接题库、打印、语音朗读等多种场景MathML 对“结构化”的支持更稳分式、矩阵这些元素在 MathML 里都有标准节点。OMML 和 MathML 的标签对应关系是相对固定的。比如 OMML 里的m:f是分式对应 MathML 的mfracm:rad是根号对应msqrt或mrootm:sSub是下标对应msub。所以转换可以用一个映射表驱动配合递归遍历var tagMap { f: mfrac, rad: msqrt, sSub: msub, sSup: msup, sSubSup: msubsup, d: mi, // 简化示意实际要根据内容类型细分 num: mn, e: mi, func: mo, // ... 更多映射 }; function ommlToMathML(node) { var tag node.localName || node.tagName; var mapped tagMap[tag]; if (!mapped) { // 无映射的直接递归子节点 var inner ; for (var i 0; i node.children.length; i) { inner ommlToMathML(node.children[i]); } return inner; } var inner ; for (var j 0; j node.children.length; j) { inner ommlToMathML(node.children[j]); } return mapped inner / mapped ; }这段代码是示意实际工程里还要处理m:eqArr公式数组、m:d括号分隔符、m:bar上下划线、矩阵的m:m结构等特殊情况。处理的原则很简单优先能转的标准结构实在转不了的复杂结构保留一个公式源码标识前端渲染时用 fallback 模式处理不要让一条公式卡死整个页面。3.5 第五步编辑器配置放行 MathML 标签这一步特别容易被忽略。百度编辑器的过滤机制默认会清掉很多自定义标签MathML 的math、mrow、mfrac、msqrt这些标签如果不提前加到白名单配置里存进去的内容刷新一下就没了或者被编辑器自动改成纯文本。我在用某个版本的编辑器时就踩过这个坑公式转换得挺好一保存全没了查了半天才发现是过滤规则直接把math标签当成非法自定义标签清除了。所以要在编辑器初始化配置里明确放行 MathML 相关节点UE.getEditor(content, { // 示意配置实际字段名以你使用版本为准 allowTags: true, filterTxtRules: { math: [], mrow: [], mfrac: [], msqrt: [], mroot: [], msub: [], msup: [], msubsup: [], munder: [], mtable: [], mtr: [], mtd: [], mo: [], mi: [], mn: [], mspace: [], mover: [], munderover: [], mphantom: [], mtext: [], semantics: [], annotation: [], } });配置的粒度要稍微细一点宁可多放行几个标准标签也不要只放行一个math否则内部结构标签会被层层过滤公式依然保不住。3.6 第六步页面端按需渲染与缓存内容发布后前端面临一个新的性能考验如果页面上一百个公式同时渲染就算用的是 KaTeX主线程也会被长时间占用。所以我在页面端加了按需渲染机制先用一个轻量的占位节点承载公式内容只有公式滚动进入视口附近时才触发渲染。实现上用的是 IntersectionObserver这个 API 兼容性已经很成熟使用方式也很直接var observer new IntersectionObserver(function (entries) { entries.forEach(function (entry) { if (!entry.isIntersecting) return; var box entry.target; renderFormula(box); observer.unobserve(box); }); }, { rootMargin: 200px }); var formulaBoxes document.querySelectorAll(.formula-box); formulaBoxes.forEach(function (box) { observer.observe(box); });这里rootMargin: 200px的含义是公式距视口底部还有 200 像素时就开始渲染。这样用户滑到公式位置时公式已经渲染好了感知上是“即时出现”。如果等公式完全出现在视口里再开始渲染用户会看到一段明显的空白等待时间。渲染函数里再把结果缓存到localStorage避免同一道题反复渲染function renderFormula(box) { var latex box.getAttribute(data-formula); if (!latex) return; var key katex: hashString(latex); var cached localStorage.getItem(key); if (cached) { box.innerHTML cached; return; } try { var html katex.renderToString(latex, { throwOnError: false, displayMode: box.dataset.display block }); localStorage.setItem(key, html); box.innerHTML html; } catch (e) { // 渲染失败时显示源码保证内容不丢 box.textContent latex; } } function hashString(str) { var hash 0; for (var i 0; i str.length; i) { var chr str.charCodeAt(i); hash ((hash 5) - hash) chr; hash | 0; } return String(hash); }缓存时用一个基于公式内容哈希的 key比直接存整篇页面结果要灵活得多。同一个公式如果出现在试卷和讲义两个页面里渲染结果可以共享公式内容稍有变动哈希变化就会重新渲染不会出现更新后缓存不刷新的问题。4. 实操排查手册几个典型的公式渲染问题4.1 公式粘贴进去变成大段乱码这个问题十有七八是 OMML 标签没有完整提取或者编辑器过滤配置没放行 MathML。排查路径分两步先在粘贴处理函数里打日志把剪贴板 HTML 的结构打印出来确认m:oMath是否存在再检查编辑器过滤配置看math、mrow这类标签有没有被白名单放行。我在实际项目里遇到过一次很隐蔽的情况公式本身是识别到了转换也对但某个版本的编辑器会在beforepaste之外再走一套自己的粘贴过滤把我们插入的 MathML 给二次清洗了。这种场景要在插入后监听一次内容变化验证最终进到编辑区域里是否还是 MathML如果不是就在afterpaste钩子里做一次补救。4.2 矩阵、分段函数打印出来结构错乱矩阵和分段函数是 OMML 转换中最容易出问题的部分。Word 里一个矩阵由m:m标签包裹内部用m:mr表示行、m:mc表示列但粘贴到 HTML 后这个结构可能被编辑器改写成table标签。MathML 里表示矩阵用的是mtable和table语义上有本质区别。如果转换逻辑只做了标签改名没有处理行列嵌套关系就会把矩阵的三行两列拍平成一行六个元素。我的处理办法是在转换前先判断节点里是否存在表格语义的标签如果有先恢复成矩阵专用的层级关系再映射为mtable。经过这一层处理矩阵列对齐的显示效果才会正确。4.3 公式渲染后把整行撑高文字上下跳动公式是行内元素默认的inline布局会让它跟随着基线上下移动尤其是带分式、根号的公式一出现就把行高撑大页面看起来一跳一跳的。解决方案是给公式容器统一设置内联块级布局和垂直对齐.formula-box { display: inline-block; vertical-align: middle; line-height: normal; max-width: 100%; overflow-x: auto; overflow-y: hidden; padding: 2px 0; }vertical-align: middle能让公式和周围文字在视觉上处于同一水平线上line-height: normal可以避免公式继承外层大行高导致间距失控。对于特别宽的公式我建议保留横向滚动或者缩小字级而不是硬塞进固定宽度容器里换行——数学公式换行会严重破坏语义。4.4 公式刷新后再次闪烁或延迟这个问题本质是没有缓存命中的二次渲染。浏览器刷新页面JS 文件重新加载所有公式重新扫描如果每个公式都要从零渲染闪一下白页或者布局抖动就出现了。我在前面加了localStorage缓存后这个问题基本消失。需要注意一个边界如果用户浏览器禁用了本地存储或者隐私模式下存储写入失败渲染代码要能自动降级到直接渲染不能因为写缓存抛异常阻塞主流程。function safeSetCache(key, value) { try { localStorage.setItem(key, value); } catch (e) { // 隐私模式或存储满时静默失败不影响渲染 } }4.5 不想大改编辑器源码怎么保证后续能升级百度编辑器是第三方开源产品团队经常要跟着上游升级版本。如果优化逻辑全写在编辑器源码里升级一次代码冲突一次。我建议把所有优化逻辑做成一个独立的补丁脚本用事件监听和配置注入的方式挂到编辑器实例上不动核心源码。这样升级时只需要重新评估挂载点是否变化不用反复合并一大堆改动。实际项目里我维护的是一个单独的formula-patch.js注册为编辑器插件内部靠beforepaste、afterpaste事件驱动效果一样但维护成本低很多。5. 常见问题速查表问题现象可能原因处理思路优先级公式粘贴后乱码OMML 提取不完整、MathML 标签被过滤用 XML 解析提取检查编辑器白名单配置高公式显示一半或结构错乱矩阵、分段函数的层级结构在转换中被拍平转换前恢复行列语义再映射为 mtable高页面卡顿输入延迟明显公式 DOM 节点过多一次性全量渲染入院清洗 轻量标记存储 按需渲染高刷新页面后公式重新闪烁没有缓存渲染结果用内容哈希做 localStorage 缓存中公式把行高撑开排版跳动行内布局导致基线漂移设置 inline-block、vertical-align middle中保存后公式消失编辑器过滤规则清除了 MathML 标签在配置中用标签白名单放行高复杂积分、矩阵显示异常KaTeX 对极复杂结构支持有限设置 fallback 模式保留源码中公式搜索不到存储的是渲染标记而非可索引文本做 SEO 版本时额外生成无障碍文本低6. 最终效果与经验沉淀优化上线后我用一份包含 126 个公式的模拟试卷页做了压测对比。优化前页面可交互时间大概是 2.8 秒公式区域滚动时频繁掉帧优化后首屏公式渲染时间降到 180 毫秒以内滚动到后续公式时因为 IntersectionObserver 提前触发渲染用户几乎感知不到加载过程。内容存储体积也从平均每页 400KB 降到 80KB 左右后端接口响应也随之快了不少。这里面最让我觉得值得反复强调的是那句心得公式渲染慢很少是某一个环节的问题而是一整条链路都在替 Word 的私有格式买单。优化不应该只盯着前端渲染引擎调参数而是要把从剪贴板开始的每个环节都做一次“减重”入口清得越干净后面每一步都越轻松。最后分享一个小技巧排查公式问题时不要只在编辑器界面里看结果要直接打开开发者工具查看编辑器区域实际的 DOM 结构。公式标签是否完整、嵌套层级是否合理、样式是否冗余一眼就能看明白。掌握了这个方法你会发现自己排查公式渲染问题的速度比同事快不止一倍。