簡介Canvas-editor是一款基于TypeScript編寫的高靈活性編輯器其Vue3可運(yùn)行源碼包面向需要將此類編輯器集成到業(yè)務(wù)系統(tǒng)中的前端開發(fā)者尤其適合官方文檔不夠直觀時希望通過源碼學(xué)習(xí)和二次定制的場景。壓縮包為zip格式共十一個文件整體僅24KB體積十分輕量。其中兩個Vue文件是編輯器核心封裝組件兩個JS文件承擔(dān)入口與邏輯裝配三個HTML文件可在瀏覽器中直接打開用于演示效果兩個JSON文件管理依賴和構(gòu)建配置另附.gitignore與.inscode輔助文件目錄結(jié)構(gòu)清晰便于按需核驗初始化參數(shù)、組件注冊和依賴安裝方式。資源內(nèi)還重點梳理了集成過程中的關(guān)鍵環(huán)節(jié)如何復(fù)制核心組件、完成配置項初始化并總結(jié)了常見適配問題、只讀模式控制以及新增功能的實現(xiàn)思路可作為排錯與二次開發(fā)的參考。作者也分享了實際項目中的修改和定制方案幫助讀者依據(jù)自身需求快速調(diào)整。已有221人學(xué)習(xí)下載適合希望掌握Canvas-editor在Vue3中集成細(xì)節(jié)并希望靈活擴(kuò)展編輯器能力的前端工程師。1. Vue3項目里的Canvas渲染富文本為什么你不用再糾結(jié)contenteditable做Web富文本編輯器絕大多數(shù)團(tuán)隊第一反應(yīng)是套一個基于contenteditable的庫。但凡是做過三年以上前端的人基本都遇到過這類編輯器帶來的光標(biāo)錯亂、粘貼樣式污染、移動端鍵盤頂起頁面等一系列問題。某公司內(nèi)部有個知識庫項目最早用的是原生contenteditable方案線上問題工單里三分之一是編輯體驗相關(guān)的后來整體重構(gòu)換成Canvas渲染內(nèi)核的編輯器問題數(shù)量降了一個量級。這份資源就是我在Vue3項目里把Canvas-editor跑通的完整可運(yùn)行源碼包含從npm包安裝、編輯器初始化、工具欄插件裝載到表單集成的每一步代碼附帶我們實際開發(fā)中踩過的幾個關(guān)鍵坑。它適合正在選型富文本編輯器、或者被傳統(tǒng)contenteditable編輯器折騰到想換方案的開發(fā)者也適合想理解Canvas渲染編輯器工作原理的初學(xué)者。2. 安裝與初始化從npm包到頁面第一個編輯器實例2.1 依賴拆分運(yùn)行時、插件、Vue封裝分別裝什么Canvas-editor是一個不依賴框架的編輯器內(nèi)核它本身用Canvas渲染頁面內(nèi)容所以不像傳統(tǒng)編輯器那樣操作DOM節(jié)點。項目里裝包的時候很多人只裝了編輯器本體結(jié)果一跑就報錯找不到工具欄、找不到插件入口這是因為這個體系是拆分成多個npm包配合使用的。我一般會在項目里安裝以下幾類依賴npm install canvas-editor/editor canvas-editor/plugin-link canvas-editor/plugin-image canvas-editor/plugin-highlight canvas-editor/plugin-table canvas-editor/plugin-markdown每個包的角色是不同的。canvas-editor/editor是核心運(yùn)行庫里面包含編輯器類、命令系統(tǒng)、渲染引擎和默認(rèn)樣式解析器。剩下的plugin-*系列是官方維護(hù)的擴(kuò)展插件分別負(fù)責(zé)鏈接編輯、圖片插入、代碼高亮、表格渲染和Markdown快捷輸入。注意這里插件不是一個統(tǒng)一注冊的而是按需引入后分門別類地傳給編輯器實例這一點和很多人的初印象不一樣以為裝一個包就全有了。有人問為什么不把插件全塞進(jìn)主包里。從拆包邏輯看核心庫只負(fù)責(zé)渲染和選區(qū)像是圖片上傳、鏈接彈窗這種依賴HTTP請求或后端接口的功能如果打進(jìn)核心包會導(dǎo)致編輯器無法在純本地環(huán)境運(yùn)行。拆開后你可以只裝核心包來跑一個不帶任何外部依賴的最小編輯器也可以按業(yè)務(wù)需要組合插件。2.2 初始化代碼Vue3組件里掛載CanvasEditor的完整代碼安裝完之后初始化代碼是我在組件里經(jīng)常反復(fù)寫的一套模板。核心思路是編輯器需要一個掛載點DOM元素然后實例化編輯器把工具欄需要用的插件傳給編輯器。下面是最簡單的可運(yùn)行版本。template div classeditor-container div classtoolbar-wrap reftoolbarRef/div div classeditor-wrap refeditorRef/div /div /template script setup langts import { ref, onMounted, onBeforeUnmount } from vue import Editor from canvas-editor/editor import LinkPlugin from canvas-editor/plugin-link import ImagePlugin from canvas-editor/plugin-image import HighlightPlugin from canvas-editor/plugin-highlight const toolbarRef refHTMLDivElement() const editorRef refHTMLDivElement() let instance: Editor | null null onMounted(() { instance new Editor({ target: editorRef.value, toolbar: [[bold, italic, underline], [insertImage, insertLink]], onChange: () { // 內(nèi)容變化回調(diào) } }) LinkPlugin.init(instance) ImagePlugin.init(instance) HighlightPlugin.init(instance) instance.toolbar.render(toolbarRef.value) }) /script這段代碼有幾個地方容易出錯。首先是onMounted里才實例化因為此時DOM節(jié)點才真正渲染完畢。其次是toolbar是一個二維數(shù)組每個內(nèi)層數(shù)組對應(yīng)工具欄里的一行不是一維數(shù)組寫錯的話工具欄按鈕會全部擠在同一行或者渲染異常。toolbar.render接收的DOM元素是工具欄的掛載容器這個容器和編輯器內(nèi)容區(qū)是兩個不同的div混用的話編輯器會直接渲染失敗。插件初始化必須在編輯器實例創(chuàng)建之后執(zhí)行因為每個插件的init方法內(nèi)部會向編輯器實例注冊工具欄按鈕的命令處理器。順序反過來會報錯提示找不到編輯器實例。2.3 生命周期與destroy離開頁面不釋放會出什么樣的問題這個編輯器實例持有大量Canvas上下文和事件監(jiān)聽在Vue3組件卸載時不主動銷毀問題會在切路由后爆發(fā)。最常見表現(xiàn)是控制臺拋錯說Canvas上下文已丟失、內(nèi)存持續(xù)上漲、再次進(jìn)入頁面時編輯器黑屏。我習(xí)慣在組件卸載前顯式調(diào)用銷毀方法onBeforeUnmount(() { if (instance) { instance.destroy() instance null } })這里要特別強(qiáng)調(diào)的是destroy()會清理編輯器內(nèi)部的事件監(jiān)聽和Canvas實例但不會自動清理你在外部通過instance.on之類接口注冊的額外監(jiān)聽事件。如果你給編輯器注冊過自定義事件必須在destroy之前先移除否則回調(diào)仍然會被觸發(fā)并持有組件引用出現(xiàn)典型的閉包內(nèi)存泄漏。還有一個細(xì)節(jié)destroy()執(zhí)行完之后編輯器容器里殘留的Canvas節(jié)點不會被自動清空。一般做法是直接在onBeforeUnmount里把對應(yīng)的DOM節(jié)點的innerHTML也清一遍。toolbarRef.value (toolbarRef.value.innerHTML ) editorRef.value (editorRef.value.innerHTML )這一步經(jīng)常被忽略但它對防止頁面切回時出現(xiàn)空白編輯器的作用非常明顯。真實項目中我把這套初始化邏輯封裝成了一個Vue3組件配置項通過props傳入組合式API返回編輯器和工具欄實例業(yè)務(wù)側(cè)再也不用關(guān)心生命周期問題。3. 核心接口調(diào)用值讀寫、歷史記錄與光標(biāo)操作3.1 setValue與getHTML雙向同步的時機(jī)與坑表單場景里最核心的一組接口就是寫入值和讀取值。Canvas-editor里寫入內(nèi)容用setValue讀取內(nèi)容用getHTML。但它們的接口簽名和DOM編輯器差異不小尤其是傳入格式。// 讀取編輯器內(nèi)HTML const editorHTML instance.getHTML() // 寫入HTML內(nèi)容到編輯器 instance.setValue(editorHTML)getHTML返回的是編輯器的序列化HTML字符串和傳統(tǒng)編輯器返回的HTML結(jié)構(gòu)有區(qū)別。Canvas-editor的HTML結(jié)構(gòu)是專門為Canvas渲染設(shè)計的一套標(biāo)簽體系標(biāo)簽里帶>const rawHTML response.data.content const editorHTML normalizeEditorHTML(rawHTML) instance.setValue(editorHTML)normalizeEditorHTML是我在公共函數(shù)庫里寫的一個清洗函數(shù)內(nèi)部做法是把純文本段落自動包裹成編輯器能識別的p節(jié)點、把裸圖片鏈接轉(zhuǎn)成編輯器圖片節(jié)點結(jié)構(gòu)、過濾掉編輯器不支持的自定義標(biāo)簽。這個函數(shù)能解決大概80%的內(nèi)容混亂問題剩下的20%需要在數(shù)據(jù)源頭控制在編輯器側(cè)生成的內(nèi)容。3.2 execCommand與命令隊列工具欄按鈕背后的實現(xiàn)邏輯執(zhí)行加粗、斜體、插入鏈接這類操作核心走的是execCommand接口。這個接口的簽名是execCommand(commandId, value?)第一個參數(shù)是命令名第二個參數(shù)是命令需要的附加數(shù)據(jù)。// 加粗選中文本 instance.execCommand(bold) // 給選中文本插入鏈接 instance.execCommand(insertLink, { href: https://example.com, text: 點擊訪問 }) // 插入圖片 instance.execCommand(insertImage, { src: imageUrl, width: 200, height: 150 })代碼里能看到不同命令對value參數(shù)的要求不一樣。bold這種格式化命令不需要附加數(shù)據(jù)insertLink和insertImage需要傳對象結(jié)構(gòu)字段名要和插件內(nèi)部約定一致。如果傳錯字段名比如把href寫成url編輯器不報錯但鏈接的地址是空的這類錯誤在開發(fā)階段非常隱蔽。關(guān)于命令隊列這里有一個值得了解的點Canvas-editor內(nèi)部有歷史記錄棧execCommand大部分命令會自動壓入歷史棧以便撤銷重做。但像insertImage這種會觸發(fā)異步上傳圖片的命令歷史棧的記錄是在圖片上傳完成之后才壓入的。在圖片上傳期間執(zhí)行撤銷操作你會發(fā)現(xiàn)撤銷的不是圖片插入而是之前某個格式化操作。這個行為不是bug而是命令系統(tǒng)的隊列機(jī)制導(dǎo)致的。理解了這一點做圖片上傳時就該在異步回調(diào)里提示用戶正在上傳請稍后操作而不是讓用戶覺得撤銷失效。3.3 監(jiān)聽contentChange什么時候觸發(fā)、為什么比DOM事件慢編輯器內(nèi)容變化的回調(diào)官方叫onChange或通過on()接口監(jiān)聽contentChange事件。初用者很容易踩一個時間差坑輸入文字后立即讀取getHTML()拿到的內(nèi)容可能還是上一次的舊值。這個現(xiàn)象的根本原因是Canvas渲染編輯器的內(nèi)容變更檢測機(jī)制。DOM編輯器在每次輸入后DOM立刻變化同步讀取沒問題。但Canvas-editor需要先把輸入事件接收到、同步到內(nèi)部模型、再走一遍Canvas重繪流程最后才觸發(fā)contentChange事件。這個流程是異步的觸發(fā)時機(jī)在重繪完成之后。我一般會在設(shè)置onChange回調(diào)時做一個約定所有業(yè)務(wù)側(cè)對編輯器內(nèi)容的使用都必須放在這個回調(diào)里讀值不在外部用定時器或事件同步讀。instance.on(contentChange, () { const content instance.getHTML() emit(update:modelValue, content) })另一個細(xì)節(jié)是contentChange不是每個鍵都觸發(fā)的。比如直接調(diào)用setValue寫入一份相同內(nèi)容編輯器對比后判定沒變化事件不會觸發(fā)。光標(biāo)位置移動、選區(qū)變化這類操作也不會觸發(fā)內(nèi)容變更事件但會觸發(fā)rangeChange事件。這兩個事件分工不同不要把它們混在一起用。如果你需要監(jiān)聽編輯器內(nèi)容之外的其他狀態(tài)比如選區(qū)變化去控制工具欄按鈕的禁用態(tài)用rangeChange事件會更合適instance.on(rangeChange, (range) { // 根據(jù)選區(qū)更新工具欄按鈕狀態(tài) const hasSelection !range.isCollapsed updateToolbarState(hasSelection) })rangeChange的觸發(fā)頻率比contentChange高得多鼠標(biāo)拖選、鍵盤方向鍵移動都會觸發(fā)。在里面放重邏輯會導(dǎo)致頁面掉幀一般只做輕量狀態(tài)更新。4. 插件機(jī)制與樣式定制把編輯器做成產(chǎn)品形態(tài)4.1 官方插件鏈link、image、highlight等插件的裝載順序插件系統(tǒng)的裝載順序?qū)τ诘谝淮斡玫娜硕允莻€玄學(xué)問題。我一開始也是憑直覺裝結(jié)果遇到工具欄按鈕渲染了但點擊沒反應(yīng)、或者插件彈窗能開但確定按鈕執(zhí)行失敗這類問題。后來逐步排查才搞明白插件裝載順序有它的內(nèi)在邏輯。先看一段典型的插件裝載代碼import Editor from canvas-editor/editor import LinkPlugin from canvas-editor/plugin-link import ImagePlugin from canvas-editor/plugin-image import TablePlugin from canvas-editor/plugin-table import HighlightPlugin from canvas-editor/plugin-highlight let editorInstance new Editor({ target: editorContainer }) // 先裝載基礎(chǔ)能力 LinkPlugin.init(editorInstance) ImagePlugin.init(editorInstance) // 再裝載表格與高亮 TablePlugin.init(editorInstance) HighlightPlugin.init(editorInstance)推薦順序是鏈接、圖片這類基礎(chǔ)塊級元素插件先裝表格、高亮這類復(fù)合能力后裝。原因是表格插件內(nèi)部會使用鏈接和圖片的節(jié)點解析能力在初始化時它可能會注冊自己的命令依賴基礎(chǔ)插件的服務(wù)接口。雖然這個依賴關(guān)系不是強(qiáng)制的即反著裝也不會直接報錯但反著裝遇到復(fù)雜混合內(nèi)容時表格里的圖片可能會渲染成裸露的HTML文本。關(guān)于高亮插件它依賴一個獨(dú)立的代碼解析庫。裝載高亮插件之前需要確保項目中已經(jīng)安裝了它依賴的語言包和樣式包否則代碼塊渲染出來是純文本沒有任何顏色。這個依賴關(guān)系在官方文檔里寫得很淺很多人在這一步浪費(fèi)時間排查。插件本身還支持自定義配置。拿鏈接插件舉例LinkPlugin.init(editorInstance, { onConfirm: (link) { console.log(link url:, link.href) return true } })配置項里可以傳入回調(diào)函數(shù)在用戶點擊確定插入鏈接時攔截處理。這里返回true表示允許編輯器執(zhí)行后續(xù)插入邏輯返回false則取消插入。這個機(jī)制可以用來做鏈接白名單校驗、跳轉(zhuǎn)前權(quán)限判斷等業(yè)務(wù)邏輯不把安全性完全交給編輯器內(nèi)核。4.2 定制工具欄按需取舍功能按鈕的配置方式Canvas-editor的工具欄不是固定一排按鈕讓你選顯隱而是通過數(shù)組配置決定渲染哪些按鈕以及按鈕的排列組合方式。這個設(shè)計靈活度很高但初期的學(xué)習(xí)成本也不低。工具欄配置結(jié)構(gòu)如下const toolbarConfig [ [undo, redo], [bold, italic, underline, strikeThrough], [fontSize, fontFamily, color, highlight], [insertImage, insertLink, insertTable], [left, center, right] ]每個內(nèi)層數(shù)組是一行工具欄數(shù)組內(nèi)的每個元素是一個按鈕的命令I(lǐng)D。這里注意幾個容易踩的點其一命令I(lǐng)D字符串必須和編輯器內(nèi)部注冊的命令保持一致寫錯一個字母工具欄整行渲染會中斷。比strikeThrough的大小寫寫錯成strikethrough會靜默失敗按鈕不出現(xiàn)。其二工具欄按鈕的順序和最終展示順序一致但格式按鈕和塊級操作按鈕混排時需要手動加分割線。配置里沒有直接的分隔線選項可以通過插入一個特殊字符串實現(xiàn)const toolbarConfig [ [undo, redo, |, bold, italic] ]|會被渲染為工具欄分隔線但它不是編輯器命令純UI標(biāo)記。這個技巧很容易在查閱源碼時發(fā)現(xiàn)官方文檔一般不細(xì)講。其三有些命令依賴插件已裝載。比如把insertImage放進(jìn)工具欄配置但前面沒有執(zhí)行ImagePlugin.init按鈕照樣渲染出來不過點擊沒有任何反應(yīng)控制臺也不會報錯。這個問題在調(diào)試時非常誤事我排查過一次最后發(fā)現(xiàn)是插件裝載被注釋掉了。4.3 樣式隔離Canvas編輯器覆蓋主題色的正確姿勢Canvas編輯器的樣式系統(tǒng)和普通DOM組件完全不同。工具欄、彈窗這類外圍UI走的是普通CSS但編輯器內(nèi)容區(qū)內(nèi)部所有渲染都在Canvas畫布上完成顏色、字體、行高等樣式都是通過編輯器實例的配置項或API設(shè)置的不是簡單的CSS覆蓋。覆蓋編輯器內(nèi)部樣式的正確做法是在初始化時傳入主題配置const editorInstance new Editor({ target: container, color: #2c3e50, background: #ffffff, fontSize: 16, lineHeight: 1.75, fontFamily: PingFang SC, Microsoft YaHei, sans-serif, defaultStyle: { font-size: 16px, line-height: 1.75 } })這些配置項中color和background控制整個編輯區(qū)的文字顏色和底色fontSize和lineHeight控制默認(rèn)字號和行高。值得提醒的是color和background的值必須是合法的CSS顏色格式否則編輯器啟動階段會拋異常。如果你想把工具欄區(qū)域也改成你自己的品牌色工具欄區(qū)域的樣式是可以通過CSS覆蓋的。比如.editor-container .toolbar-wrap { background-color: #f6f8fa; border-bottom: 1px solid #e1e4e8; }但這些CSS只會作用于工具欄和彈窗外殼不會滲透到Canvas內(nèi)部的文字渲染。想改編輯器內(nèi)部某一類元素的樣式比如讓所有鏈接顯示為主題色需要在編輯器初始化后調(diào)用樣式接口editorInstance.setStyle({ a: { color: #1a73e8, textDecoration: underline } })setStyle接口接收一個對象key是元素標(biāo)簽名value是樣式對象或CSS字符串。這里能設(shè)的樣式受限于Canvas渲染能力比如不支持box-shadow這類復(fù)雜效果陰影和圖標(biāo)的渲染需要額外的插件支持。理解了這條邊界定制編輯器視覺時才不會在錯誤的方向上浪費(fèi)時間。5. 避坑canvas編輯器最常見的五個翻車現(xiàn)場5.1 現(xiàn)象一編輯器寬度撐不滿容器內(nèi)部文字換行錯亂編輯器渲染出來后寬度沒有跟隨父容器自適應(yīng)文字換行位置看起來完全隨機(jī)。檢查后發(fā)現(xiàn)問題不在編輯器配置而在容器CSS。設(shè)置編輯器style屬性傳入的是width: 100%但父容器本身沒有明確寬度導(dǎo)致編輯器初始化時拿到的是0px或無效寬度Canvas繪制時只能按默認(rèn)寬度渲染。解決方式是確保父容器在編輯器初始化前已經(jīng)完成布局并具有確定寬度。在Vue3中如果在onMounted時父容器的寬度還要依賴異步數(shù)據(jù)計算需要等待寬度計算完成后再實例化編輯器或使用nextTick后再執(zhí)行初始化。await nextTick() editorInstance new Editor({ target: container })還有一個間接原因是初始化后容器寬度變化了比如側(cè)邊欄折疊導(dǎo)致主區(qū)域變寬編輯器不會自動重新測量Canvas寬度。需要手動調(diào)用重排editorInstance.repaint()在側(cè)邊欄折疊事件回調(diào)里執(zhí)行這個操作編輯器會重新計算寬度并重繪畫布文字換行就會恢復(fù)正常。5.2 現(xiàn)象二切換路由后再次進(jìn)入頁面卡死或白屏進(jìn)入頁面編輯器能正常使用切走再切回來頁面卡死或編輯器區(qū)域白屏。這種情況十有八九是編輯器實例沒有銷毀或者銷毀不徹底。前面提到過onBeforeUnmount中要調(diào)用destroy()并清理DOM節(jié)點。但還有一種情況是你沒有在onBeforeUnmount中銷毀而是依賴Vue3的KeepAlive緩存頁面組件被緩存了但編輯器實例在某個時點被外部拿走了引用。等再次激活時原來的Canvas已經(jīng)被瀏覽器回收重新渲染就出現(xiàn)白屏。解決思路是不要依賴KeepAlive去管理編輯器實例的生命周期。在onActivated時檢查實例是否存在不存在就重新初始化在onDeactivated時銷毀。表單類的編輯器建議完全不使用KeepAlive用顯式的v-if切換加onMounted初始化替代。5.3 現(xiàn)象三setValue輸入HTML后樣式丟失、圖片不顯示通過setValue把一段含圖片的HTML塞給編輯器結(jié)果文字有內(nèi)容、樣式全部丟失圖片直接不顯示或顯示為破圖。這個問題的根源是Canvas-editor不認(rèn)識非它自己生成的HTML結(jié)構(gòu)。解決方式在setValue之前做一層轉(zhuǎn)換。最實用的是把HTML字符串轉(zhuǎn)換成編輯器能識別的節(jié)點結(jié)構(gòu)這一步可以在前端做也可以在后端做。前端做的話我通常寫一個公共轉(zhuǎn)換函數(shù)把常規(guī)的p、img、a標(biāo)簽結(jié)構(gòu)轉(zhuǎn)為編輯器預(yù)期的帶>instance.trigger(contentChange)如果回調(diào)執(zhí)行了說明注冊邏輯正常問題出在內(nèi)容變更檢測本身。如果沒執(zhí)行檢查實例初始化的onChange寫的是不是字符串而不是函數(shù)。5.5 現(xiàn)象五工具欄按鈕全部灰色點擊無響應(yīng)編輯器內(nèi)容區(qū)和工具欄都正常渲染但所有按鈕灰色不可點或者能點但沒有效果。這是最讓人頭疼的一種狀態(tài)。按鈕灰色一般是編輯器實例沒有設(shè)置readonly: false或?qū)嵗驗槟撤N原因進(jìn)入了只讀模式。Canvas-editor初始化時readonly模式默認(rèn)是關(guān)閉的但如果你在初始化后調(diào)用了instance.setReadonly(true)就會遇到這樣的問題。檢查初始化參數(shù)把readonly顯式設(shè)為false。按鈕能點但沒效果則要檢查命令執(zhí)行時是否選中了文本。Canvas-editor的加粗、斜體這類命令需要選區(qū)存在才有效果沒有選區(qū)的情況下執(zhí)行這些命令會被內(nèi)部攔截。這不算bug但普通用戶會認(rèn)為按鈕壞了。排查思路是在選擇文本狀態(tài)下看按鈕是否可用再用instance.getRange()查看當(dāng)前選區(qū)是否存在。6. 進(jìn)階表單場景里把編輯器包成受控組件編輯器跑通后下一個需求一定是把它塞進(jìn)表單。Canvas-editor本身不是一個受控組件它的值變化不會自動同步到表單狀態(tài)需要我們在外面做一層封裝。我日常的習(xí)慣是把它封裝成一個Vue3受控組件對外暴露v-model。封裝的核心是處理好兩個方向的同步外部值變化時更新編輯器內(nèi)容編輯器內(nèi)部變化時通知外部更新。template div refcontainer classrich-editor/div /template script setup langts import { ref, watch, onMounted, onBeforeUnmount } from vue import Editor from canvas-editor/editor const props defineProps{ modelValue: string }() const emit defineEmits{ (e: update:modelValue, value: string): void }() const container refHTMLDivElement() let editor: Editor | null null let isInternalChange false onMounted(() { if (!container.value) return editor new Editor({ target: container.value, toolbar: [[bold, italic]] }) editor.setValue(props.modelValue || ) editor.on(contentChange, () { isInternalChange true emit(update:modelValue, editor!.getHTML()) }) }) watch(() props.modelValue, (newVal) { if (!editor) return if (!isInternalChange) { const current editor.getHTML() if (current ! newVal) { editor.setValue(newVal || ) } } isInternalChange false }) onBeforeUnmount(() { if (editor) { editor.destroy() editor null } }) /scriptisInternalChange這個標(biāo)志位是防止死循環(huán)的關(guān)鍵。編輯器內(nèi)部觸發(fā)變更會emit更新父組件值父組件值變化又觸發(fā)watch去setValuesetValue本身在內(nèi)容不同時又會觸發(fā)contentChange這樣會形成無限循環(huán)。通過標(biāo)志位打斷這個鏈路后外部回顯和內(nèi)部輸入互不干擾。表單校驗部分我一般會把編輯器內(nèi)容按純文本計算長度而不是直接取HTMLfunction getPlainText(html: string): string { const div document.createElement(div) div.innerHTML html return div.textContent || }校驗規(guī)則里字?jǐn)?shù)限制基于純文本長度避免HTML標(biāo)簽計入字?jǐn)?shù)。這是產(chǎn)品側(cè)很常見的需求在封裝組件時提前內(nèi)置這個能力會讓表單校驗省很多事。實際項目里我還加了一個防抖邏輯把contentChange觸發(fā)時的emit操作延遲300ms執(zhí)行避免用戶輸入過程中高頻觸發(fā)父組件重新渲染減少大內(nèi)容編輯時的卡頓感。這套封裝從第一次做表單集成開始后來被我在模擬項目X和某跨平臺系統(tǒng)中反復(fù)復(fù)用。從那以后我在每次接富文本編輯器需求時都會強(qiáng)制走一遍受控組件封裝流程先把值同步鏈路理清再寫業(yè)務(wù)邏輯幾乎沒有再遇到過同步丟數(shù)據(jù)的問題。希望幫到你這包代碼直接跑起來改改就能用。本文還有配套的精品資源點擊獲取