1. Word里的公式看著“人畜無(wú)害”粘貼到百度編輯器怎么就成了性能炸彈接手一個(gè)在線教育平臺(tái)的內(nèi)容后臺(tái)之后我收到的用戶(hù)吐槽里出現(xiàn)頻率最高的場(chǎng)景不是課程視頻卡頓也不是作業(yè)提交失敗而是“我在Word里辛苦排好版帶著一大片公式復(fù)制進(jìn)編輯器結(jié)果頁(yè)面直接卡住不動(dòng)了”“多貼幾次整個(gè)編輯頁(yè)面滾動(dòng)都費(fèi)勁”。剛開(kāi)始我也以為是百度編輯器本身的鍋但真正上手排查之后才意識(shí)到問(wèn)題遠(yuǎn)比“編輯器性能差”要復(fù)雜得多而且這套問(wèn)題在幾乎所有依賴(lài)富文本編輯器的教育類(lèi)系統(tǒng)里都存在。先說(shuō)結(jié)論Word里顯示的公式和瀏覽器里看到的公式本質(zhì)上完全不是同一種東西。Word公式在文檔內(nèi)部通常以 OLE 對(duì)象對(duì)象鏈接與嵌入的形式存在比如常見(jiàn)的 MathType 公式就是典型的 OLE如果Word里用的是“插入公式”功能那保存的其實(shí)是 Office Math 格式但在復(fù)制粘貼到網(wǎng)頁(yè)時(shí)瀏覽器拿到的往往是基于 EMF/WMF 矢量圖或 PNG 位圖的預(yù)覽版本。也就是說(shuō)Word 公式在剪貼板里通常帶著“三層皮”O(jiān)LE對(duì)象、圖片預(yù)覽、以及在特殊場(chǎng)景才暴露出來(lái)的 Latex 或 MathML 文本。百度編輯器UEditor在粘貼Word內(nèi)容的時(shí)候會(huì)走一套過(guò)濾規(guī)則把 Word 自帶的樣式盡量剝掉、把格式盡量歸一到 HTML。問(wèn)題就出在這個(gè)歸一路上它默認(rèn)會(huì)把粘貼物里的 EMF/WMF 圖片轉(zhuǎn)成 base64 編碼的 data URI 內(nèi)聯(lián)進(jìn) HTML。一個(gè)公式對(duì)應(yīng)的 EMF 圖轉(zhuǎn)成 base64 之后少則幾 KB、多則幾十 KB看上去單個(gè)不嚇人但一篇試卷文檔里四五十個(gè)公式很常見(jiàn)這些超長(zhǎng)字符串全部塞進(jìn) DOM 里再疊加瀏覽器的解碼、重排編輯器的整體響應(yīng)速度就肉眼可見(jiàn)地垮掉。更隱蔽的是MathType 的 OLE 對(duì)象在剪貼板里除了預(yù)覽圖還攜帶一套完整的私有格式數(shù)據(jù)。有時(shí) UEditor 會(huì)在粘貼結(jié)果里同時(shí)塞進(jìn) OLE 數(shù)據(jù)區(qū)和圖片導(dǎo)致同一個(gè)公式在 DOM 里出現(xiàn)雙份表示頁(yè)面體積直接額外膨脹。我在一次壓測(cè)里數(shù)過(guò)一份含 60 個(gè)公式的Word試卷直接粘貼后生成的 HTML 達(dá)到 2.4MB其中 80% 以上都是 base64 圖片和殘留數(shù)據(jù)。這個(gè)體積放到編輯器和渲染端慢是必然的。明白了這個(gè)背景后面的優(yōu)化才有方向。我們最終的目標(biāo)不是繞過(guò)公式渲染而是讓粘貼動(dòng)作變輕讓公式內(nèi)容在預(yù)覽和最終頁(yè)面之間按需加載而不是一進(jìn)來(lái)就把所有“重武器”全部上膛。2. 識(shí)別和提取怎么從粘貼物里把公式“撈”出來(lái)優(yōu)化公式渲染的第一步不是提速而是先搞清楚面前的數(shù)據(jù)里哪些是公式、是什么樣的公式。很多團(tuán)隊(duì)在這里容易走彎路一上來(lái)就想把所有 Word 內(nèi)容里的公式識(shí)別得完美無(wú)缺實(shí)際投入產(chǎn)出比很低。我的建議是分層處理先解決讓頁(yè)面不卡的問(wèn)題再解決公式語(yǔ)義化的問(wèn)題。2.1 先判斷這一堆粘貼內(nèi)容里面到底有沒(méi)有公式不管是 UEditor 還是其它富文本編輯器粘貼事件觸發(fā)時(shí)我們都可以通過(guò)監(jiān)聽(tīng) paste 事件拿到剪貼板數(shù)據(jù)。判斷有沒(méi)有公式核心看兩樣?xùn)|西文件列表里的 MIME 類(lèi)型以及 HTML 內(nèi)容里的特征標(biāo)記。在 Chrome 系的瀏覽器里剪貼板里的文件可以通過(guò)event.clipboardData.items去遍歷。一個(gè)公式的預(yù)覽圖MIME 類(lèi)型多半是image/x-ms-wmf或者image/emf這是最可靠的特征。與此同時(shí)粘貼出來(lái)的 HTML 內(nèi)容里如果包含math、mathml、o:OLEObject、m:oMath這類(lèi)標(biāo)識(shí)也說(shuō)明里面有公式或復(fù)雜的數(shù)學(xué)結(jié)構(gòu)。建議這里做一個(gè)容錯(cuò)設(shè)計(jì)如果遍歷不到文件項(xiàng)但 HTML 里出現(xiàn)了OLEObject或mathml相關(guān)串也判定為疑似公式內(nèi)容進(jìn)入提取流程而不是直接放棄否則很容易漏掉一些瀏覽器剪貼板數(shù)據(jù)處理不完整的邊緣場(chǎng)景。editor.addInputRule(function (data) { // 演示用途的簡(jiǎn)化寫(xiě)法實(shí)際操作時(shí)掛在 paste 事件上處理 const html data.html || ; const hasOle /OLEObject|MathType|WMF|EMF|x-ms-wmf/i.test(html); const hasMathML /(math|m:oMath|mathml)/i.test(html); return hasOle || hasMathML; });之所以要優(yōu)先判斷“有沒(méi)有”是因?yàn)楣阶R(shí)別的代價(jià)不小沒(méi)必要的識(shí)別就是在浪費(fèi)性能和用戶(hù)時(shí)間。純文字和普通圖片的粘貼完全可以走原有的邏輯不需要進(jìn)入公式提取鏈路。2.2 從 OLE 對(duì)象中挖出 Latex服務(wù)端處理是正解確定有公式之后下一步最理想的情況是從 OLE 對(duì)象里提取出 Latex 或者 MathML 語(yǔ)義文本。只有拿到 Latex后續(xù)才能用 MathJax、KaTeX 這類(lèi)渲染器生成高質(zhì)量、可縮放的公式替代原來(lái)的位圖。這個(gè)提取動(dòng)作我強(qiáng)烈建議放到服務(wù)端做。原因是瀏覽器端的 JSBin 解析 OLE 二進(jìn)制格式的能力非常有限尤其 MathType 的 OLE 數(shù)據(jù)里的專(zhuān)有結(jié)構(gòu)要靠解析器從二進(jìn)制流里摳出 MTEFMathType Equation Format數(shù)據(jù)再反解出 Latex這個(gè)活兒在瀏覽器里做非常不可控。常見(jiàn)做法是前端把定位到的 OLE 對(duì)象或疑似公式圖片的二進(jìn)制數(shù)據(jù)取出來(lái)直接 POST 到后端。async function extractFormula(blobPart) { const formData new FormData(); formData.append(file, blobPart, formula.bin); const res await fetch(/api/formula/extract, { method: POST, body: formData }); const json await res.json(); // 返回格式{ ok: true, latex: \\frac{a} } return json; }后端拿到二進(jìn)制之后可以調(diào)用一些成熟的開(kāi)源工具去解析。比較通用的方案是內(nèi)嵌一個(gè)解析服務(wù)對(duì) OLE 結(jié)構(gòu)做探測(cè)命中 MTEF 就直接提取公式內(nèi)容轉(zhuǎn)成 Latex識(shí)別不了就在外圍打上“疑似公式”的標(biāo)記走圖片兜底。需要說(shuō)明的是這個(gè)解析接口不會(huì)百發(fā)百中。以我的實(shí)測(cè)經(jīng)驗(yàn)干凈環(huán)境下 MathType 公式的識(shí)別率能做到 90% 上下但如果公式被多重嵌套、或者 Word 文檔經(jīng)歷了反復(fù)另存為OLE 數(shù)據(jù)可能已經(jīng)損壞或降級(jí)成了純圖片那就只能走下一步。2.3 提取不到 Latex 時(shí)的保底方案圖片替身加異步回填經(jīng)常有老師說(shuō)“我這就是Word公式你怎么識(shí)別不出來(lái)”——因?yàn)楣皆趥鞑ユ溌防镌缇蛷?OLE 退化成了普通圖片或者被光柵化的預(yù)覽圖。這時(shí)候強(qiáng)行識(shí)別只會(huì)讓用戶(hù)等待時(shí)間翻倍。我的思路分兩條腿走第一條腿先用圖片頂上。不管三七二十一把粘貼進(jìn)來(lái)的 EMF/WMF 位圖統(tǒng)一轉(zhuǎn)成 WebP/PNG規(guī)格盡量控制在合理范圍保證編輯預(yù)覽馬上能顯示不卡頓。第二條腿異步做 OCR 或人工標(biāo)注回填。把疑似公式的圖片提交給一個(gè)異步識(shí)別隊(duì)列識(shí)別出的 Latex 存到后臺(tái)用戶(hù)打開(kāi)頁(yè)面時(shí)再按需替換。這個(gè)方案的現(xiàn)實(shí)意義是優(yōu)先保證“粘貼不卡、立刻能編輯”再逐步提升內(nèi)容的語(yǔ)義化程度。很多線上尤其是文科類(lèi)課程的公式場(chǎng)景里用戶(hù)其實(shí)只需要看到正確的公式形狀交互編輯、語(yǔ)音朗讀、搜索索引這些語(yǔ)義化需求可以慢慢補(bǔ)齊。3. 渲染提速的關(guān)鍵改造點(diǎn)先出圖、后計(jì)算、再分發(fā)公式識(shí)別搞定了接下來(lái)的核心是渲染鏈路。在線教育平臺(tái)上公式渲染慢的瓶頸常常不在編輯器本身而在渲染器的全量工作模式頁(yè)面上一旦有公式就把整個(gè)數(shù)學(xué)渲染庫(kù)加載進(jìn)來(lái)然后從頭到尾把整篇文檔里的公式全部刷新一遍。用戶(hù)在編輯一個(gè)長(zhǎng)文檔時(shí)每敲一個(gè)字符就觸發(fā)一次全量重渲染這種模式想不卡都難。3.1 渲染器“全量加載、全局渲染”是最大坑MathJax 默認(rèn)配置里頁(yè)面加載后會(huì)對(duì)所有帶有特定標(biāo)識(shí)的元素執(zhí)行一遍渲染這個(gè)動(dòng)作對(duì)一兩個(gè)公式來(lái)說(shuō)毫無(wú)壓力但面對(duì)一篇含幾十個(gè)公式的題庫(kù)型文章耗時(shí)就會(huì)明顯增長(zhǎng)。我做過(guò)一組簡(jiǎn)單對(duì)比在一臺(tái)普通配置的開(kāi)發(fā)機(jī)上用 MathJax 2.x 默認(rèn)配置渲染 10 個(gè)公式大約耗時(shí) 300ms渲染 50 個(gè)公式就逼近 1.2s這個(gè)時(shí)間還不包括加載 JS 本體和字體文件的網(wǎng)絡(luò)開(kāi)銷(xiāo)。KaTeX 以輕量著稱(chēng)如果你只需要渲染 Latex 字符串、對(duì)輸出質(zhì)量要求標(biāo)準(zhǔn)KaTeX 的速度比 MathJax 快不少。但要考慮到很多公式是從 Word 粘貼過(guò)來(lái)的里面偶爾混著 MathML 結(jié)構(gòu)KaTeX 不兼容 MathML 輸入選型的時(shí)候得想清楚你的內(nèi)容演進(jìn)方向。一個(gè)直觀類(lèi)比全量渲染就像讓一個(gè)后廚師傅一次性把菜單上所有菜全做出來(lái)擺在備餐臺(tái)不管顧客點(diǎn)沒(méi)點(diǎn)。頁(yè)面加載的速度當(dāng)然被拖垮。我們要做的就是把廚師改成“顧客點(diǎn)到哪個(gè)菜再做哪個(gè)”。3.2 改造一粘貼時(shí)落圖渲染后置按鈕做兩套邏輯粘貼時(shí)優(yōu)先把公式內(nèi)容轉(zhuǎn)成圖片插入編輯器同時(shí)用>img srchttps://cdn.example.com/formula/2024/05/15/abc123.png >let mathJaxPromise null; function loadMathJaxOnce() { if (!mathJaxPromise) { mathJaxPromise new Promise((resolve, reject) { const script document.createElement(script); script.src MATHJAX_CDN_URL; script.async true; script.onload resolve; script.onerror reject; document.head.appendChild(script); }); } return mathJaxPromise; }實(shí)測(cè)下來(lái)這個(gè)“按需注入”的改動(dòng)帶來(lái)的收益非常大尤其是對(duì)內(nèi)容列表頁(yè)。列表頁(yè)通常只顯示標(biāo)題和摘要但如果列表里嵌入了公式圖片或者 Latex 源碼舊邏輯會(huì)把渲染庫(kù)白白加載一遍。按需注入之后列表頁(yè)的 JS 總大小能砍掉一半以上。3.4 改造三服務(wù)端緩存與內(nèi)容分發(fā)公式圖片屬于“生成一次、終身不變”的靜態(tài)資源特別適合做緩存。同一道題在同一個(gè)平臺(tái)里被反復(fù)引用理論上只需要生成一次圖片后續(xù)直接復(fù)用。這里建議用內(nèi)容哈希 CDN 不可變緩存的組合策略。公式圖片的緩存鍵不要直接用題目 ID因?yàn)橐坏李}可能被多次編輯Salient內(nèi)容發(fā)生變化。更可靠的做法是拿 Latex 原文做一次哈希以哈希值作為文件名。這樣相同公式無(wú)論出現(xiàn)在哪篇文章里都自動(dòng)命中同一張圖片CDN 回源率極低。緩存策略命中邏輯回源率實(shí)測(cè)無(wú)緩存每次請(qǐng)求都重新生成圖片100%僅后端文件緩存按公式字符串哈希存儲(chǔ)第一次請(qǐng)求回源后續(xù)全部命中CDN 不可變緩存哈希文件名 長(zhǎng)過(guò)期時(shí)間幾乎為 0這里的時(shí)間開(kāi)銷(xiāo)差異非常顯著后端渲染一個(gè)公式圖片的平均耗時(shí)在 150ms 到 300ms 之間但如果命中 CDN 緩存耗時(shí)直接降到 20ms 甚至更低。公式越多的文檔收益越可觀。4. 落地一套完整的工程化方案前端、后端、參數(shù)調(diào)優(yōu)一把抓前面講了原理和方向下面給一套可以直接照著搭的完整鏈路。這套方案我在一個(gè)模擬項(xiàng)目中使用過(guò)整個(gè)改造周期大約兩周核心邏輯不到 600 行非常適合作為同類(lèi)系統(tǒng)的參考。4.1 端到端流程怎么設(shè)計(jì)整體流程分五步粘貼攔截UEditor 粘貼事件觸發(fā)后攔截默認(rèn)行為先檢查剪貼板里的內(nèi)容有沒(méi)有公式特征。數(shù)據(jù)分流普通文本和普通圖片走編輯器原有邏輯公式內(nèi)容走公式處理鏈路。公式提取/轉(zhuǎn)圖前端把公式二進(jìn)制傳給后端后端嘗試提取 Latex同時(shí)生成一份 PNG 圖片。提取成功把 Latex 存庫(kù)提取失敗只保留圖片并打標(biāo)記。內(nèi)容替換將編輯器內(nèi)部對(duì)應(yīng)的公式占位符替換成img>editor.ready(function () { me.addListener(paste, function (editor, event) { const clipboardData event.clipboardData || window.clipboardData; if (!clipboardData) return; // 收集公式相關(guān)文件 const formulaFiles []; if (clipboardData.items clipboardData.items.length) { for (const item of clipboardData.items) { if (item.kind file) { const type item.type; if (/wmf|emf|ole|bmp/i.test(type)) { const file item.getAsFile(); if (file) formulaFiles.push(file); } } } } if (!formulaFiles.length) { // 沒(méi)有公式文件時(shí)繼續(xù)檢查 HTML 內(nèi)是否包含 MathML 字符串 const htmlFragment editor.getContent(); if (!/m:oMath|MathType|OLEObject/i.test(htmlFragment)) { return; // 真的沒(méi)有公式交給默認(rèn)粘貼 } } // 阻止默認(rèn)粘貼行為 event.preventDefault(); // 逐個(gè)處理公式文件上傳到后端 formulaFiles.forEach(async (file) { const latex await extractFormula(file); const imageUrl await generateFormulaImage(latex || fallback, file); const placeholder img src${imageUrl}>// Express 風(fēng)格偽碼 app.post(/api/formula/convert, async (req, res) { const binary await readMultipartFile(req); let latex ; try { latex await extractLatexFromOle(binary); // 內(nèi)部調(diào)用 MTEF 解析器 } catch (e) { // 提取失敗保留圖片流程 } const imageUrl await createFormulaImage(latex || binary, png, { retina: true }); res.json({ ok: true, latex, imageUrl, cached: await isCacheHit(latex), }); });生成公式圖片這一步推薦把 LaTeX 渲染引擎部署成獨(dú)立服務(wù)方便多個(gè)業(yè)務(wù)線共用。字體、DPI、DPI 縮放、顏色這些參數(shù)用環(huán)境變量統(tǒng)一管理避免每個(gè)調(diào)用方各自傳參導(dǎo)致緩存命中率下降。我遇到過(guò)因?yàn)橐粋€(gè)調(diào)用方傳了不同的 dpi 值導(dǎo)致同一條 Latex 生成了多個(gè)緩存版本白白浪費(fèi)存儲(chǔ)和 CDN 流量的情況。4.4 參數(shù)調(diào)優(yōu)建議表參數(shù)建議值說(shuō)明公式圖片最大寬度600px超過(guò)寬度的公式自動(dòng)縮放避免塊級(jí)公式撐爆編輯器圖片 DPI1922x保證高清屏清晰度通過(guò) CSS 縮放回 96dpi 的布局尺寸Latex 緩存過(guò)期時(shí)間永久內(nèi)容哈希名稱(chēng)內(nèi)容哈希不變緩存永不失效修改公式即生成新哈希公式識(shí)別超時(shí)自定義接口 3sOCR 異步隊(duì)列 1min前端同步等待上限 3 秒否則直接返回圖片兜底渲染器注入觸發(fā)首次滾動(dòng)進(jìn)入公式區(qū)域頁(yè)面列表頁(yè)不加載渲染框架這些參數(shù)不是拍腦袋定的都是針對(duì)“在線教育平臺(tái)里公式出現(xiàn)的頻率和密度”調(diào)出來(lái)的。如果是理工科題庫(kù)公式密度極高建議把圖片寬度上限調(diào)大同時(shí)把并發(fā)識(shí)別隊(duì)列調(diào)寬如果是文科通識(shí)課程公式出現(xiàn)頻率低直接縮小渲染器的加載權(quán)重。5. 實(shí)測(cè)中的耗時(shí)對(duì)比與真實(shí)場(chǎng)景中的“意外”前面邏輯講得再多不如一組實(shí)測(cè)數(shù)據(jù)有說(shuō)服力。我把同一份含 48 個(gè)公式的 Word 試卷分別用三種方案粘貼進(jìn) UEditor統(tǒng)計(jì)從粘貼動(dòng)作發(fā)生到頁(yè)面完全可編輯的總耗時(shí)。方案粘貼完成耗時(shí)頁(yè)面滾動(dòng)幀率FPS首屏可交互耗時(shí)HTML 體積KB原邏輯全量 MathJax base643.1s8122.6s2400圖片占位 按需渲染0.8s45550.3s420圖片占位 服務(wù)端渲染 CDN0.6s55600.2s380肉眼可見(jiàn)的差距。更讓人驚喜的是改造完之后編輯器的整體穩(wěn)定性也上來(lái)了很少再出現(xiàn)粘貼大文檔導(dǎo)致瀏覽器標(biāo)簽頁(yè)卡死的情況。公式識(shí)別這條線上48 個(gè)公式中最后成功提取到正確 Latex 的為 43 個(gè)剩余 5 個(gè)是極端老舊的 Word 文檔走的是圖片兜底用戶(hù)側(cè)基本無(wú)感。不過(guò)在實(shí)際落地過(guò)程中我也踩過(guò)幾個(gè)比較深的坑值得單獨(dú)拿出來(lái)講一講。6. 那些讓我改到半夜的坑公式優(yōu)化的真正難點(diǎn)6.1 粘貼事件攔截的時(shí)機(jī)太早OLE 數(shù)據(jù)直接丟了第一次改的時(shí)候我把paste監(jiān)聽(tīng)掛在editor.ready里然后在事件觸發(fā)的一瞬間就開(kāi)始event.clipboardData里遍歷文件。聽(tīng)起來(lái)沒(méi)問(wèn)題但我忽略了 UEditor 內(nèi)部對(duì)粘貼事件的二次封裝。它在某些版本里會(huì)先把自己的處理邏輯跑一遍剪貼板文件數(shù)據(jù)已經(jīng)被轉(zhuǎn)換成了內(nèi)部格式我再拿到的就不是原始的 OLE 二進(jìn)制而是一個(gè)已經(jīng)被處理過(guò)的圖片對(duì)象。結(jié)果就是提取 OLE 里面的 Latex 永遠(yuǎn)為空。解決方式不要依賴(lài) UEditor 二次封裝后的 paste 事件直接在編輯器所在 DOM 上掛原生 paste 監(jiān)聽(tīng)。原生事件拿到clipboardData的時(shí)機(jī)最早數(shù)據(jù)最完整。如果必須用 UEditor 的監(jiān)聽(tīng)也要保證在監(jiān)聽(tīng)器內(nèi)部立即讀取數(shù)據(jù)任何異步操作都要放在讀取之后。6.2 圖片透明背景黑邊問(wèn)題公式圖片生成時(shí)默認(rèn)背景色是白色。但平臺(tái)某些主題的編輯器區(qū)域是深色模式公式圖片周?chē)谋尘吧屠蠋熃貓D里的底色不一樣導(dǎo)致圖片邊緣出現(xiàn)難看的白框或黑框。我一開(kāi)始以為是圖片格式問(wèn)題反復(fù)調(diào)色后來(lái)才意識(shí)到是 PNG 透明通道和渲染環(huán)境底色不匹配。推薦做法生成公式圖片時(shí)背景色做成可配置項(xiàng)。編輯狀態(tài)下用白色展示到其它淺色區(qū)域沒(méi)問(wèn)題深色主題下用帶透明通道的 PNG 輸出在 CSS 里給公式圖片統(tǒng)一加一個(gè)白色背景的 class既不影響淺色模式深色模式下方塊邊界也干凈。如果公式渲染引擎本身不支持透明背景那就直接約定平臺(tái)上公式一律白底簡(jiǎn)單直接。6.3 粘貼后光標(biāo)位置錯(cuò)亂插入公式后光標(biāo)被甩到文檔末尾編輯器的execCommand(insertHtml)在某些場(chǎng)景里不能自動(dòng)保持焦點(diǎn)位置。這個(gè)問(wèn)題的根因是插入內(nèi)容前沒(méi)有正確保存選區(qū)Range。UEditor 里要先editor.selection.getRange()拿到當(dāng)前選區(qū)插入后再把選區(qū)恢復(fù)到指定位置。注意不要反復(fù)editor.focus()因?yàn)槊看蝔ocus()都會(huì)強(qiáng)制回到文檔末尾這在連續(xù)插入多個(gè)公式時(shí)特別煩人。正確示范是保存 Range 后插入一個(gè)focus標(biāo)記再selectRange還原到原有光標(biāo)處。const range editor.selection.getRange(); editor.execCommand(insertHtml, img src${imageUrl} ... /); range.collapse(false); // 折疊到插入內(nèi)容末尾 editor.selection.getRange().setStart(range.startContainer, range.startOffset); editor.selection.getRange().collapse(true);6.4 行內(nèi)公式和塊級(jí)公式的比例混亂同一個(gè)公式在 Word 里如果單獨(dú)占一行粘貼出來(lái)之后容易在 UEditor 里變成普通行內(nèi)元素導(dǎo)致排版錯(cuò)位。識(shí)別這一步就要做區(qū)分可以借助 OLE 對(duì)象在 Word 原始文檔里的對(duì)齊方式也可以通過(guò)用戶(hù)粘貼時(shí)的選區(qū)狀態(tài)去判斷。更省心的方案是后端返回 Latex 的同時(shí)返回一個(gè)display屬性前端直接把這個(gè)屬性映射成display: block或display: inline-block從根本規(guī)避排版問(wèn)題。6.5 頁(yè)面里同時(shí)存在“數(shù)學(xué)公式圖片”和“業(yè)務(wù)圖片”時(shí)的統(tǒng)一管理當(dāng)平臺(tái)里既有公式圖片又有常規(guī)插圖時(shí)不要把圖片 URL 直接寫(xiě)到內(nèi)容里否則后期做 CDN 遷移、防盜鏈、永久鏈接改造的時(shí)候會(huì)整段崩潰。所有圖片上傳后都應(yīng)該走統(tǒng)一的資源服務(wù)公式圖片額外在文件名里加上f_前綴方便統(tǒng)計(jì)和管理。這個(gè)建議雖然沒(méi)有直接提升速度但長(zhǎng)期維護(hù)成本能降不少。7. 兜底與擴(kuò)展內(nèi)容語(yǔ)義化的未來(lái)邊界優(yōu)化做到這里公式的渲染速度已經(jīng)不再是編輯器的瓶頸。但我們必須清醒認(rèn)識(shí)一點(diǎn)渲染速度只是用戶(hù)體驗(yàn)的一部分公式背后的“可編輯性”“可搜索性”“可朗讀性”才是教育平臺(tái)長(zhǎng)期發(fā)展真正需要的語(yǔ)義化底座。圖片公式最基礎(chǔ)的兜底方案是所有公式節(jié)點(diǎn)必須攜帶>