1. 先想清楚為什么要在瀏覽器里塞一張腦圖聊 HTML5 思維腦圖插件之前得先把一個(gè)前置問題說(shuō)透你到底是需要一個(gè)看圖的頁(yè)面還是需要一個(gè)改圖的編輯器這兩個(gè)訴求對(duì)應(yīng)完全不同的技術(shù)路線選錯(cuò)了插件后面改起來(lái)比重寫還累。我在做內(nèi)部知識(shí)庫(kù)和在線課程大綱工具的時(shí)候前后踩過(guò)三輪坑。第一輪用的是最土的辦法——后端生成一張 PNG前端img一貼簡(jiǎn)單到不能再簡(jiǎn)單但用戶想改一個(gè)字都得回到后臺(tái)表單體驗(yàn)直接勸退。第二輪上了某商業(yè)圖形庫(kù)功能確實(shí)全但授權(quán)費(fèi)和包體積都不是小項(xiàng)目能扛的而且它的思維導(dǎo)圖布局是圖編輯器邏輯節(jié)點(diǎn)間距、連線拐點(diǎn)都得自己調(diào)調(diào)到最后像是在重新實(shí)現(xiàn)一遍布局算法。第三輪才老老實(shí)實(shí)回到 HTML5 生態(tài)里找現(xiàn)成插件也才有了下面這些經(jīng)驗(yàn)。HTML5 思維腦圖插件說(shuō)白了就是一組跑在瀏覽器里的 JavaScript 庫(kù)它替你干三件事把樹形數(shù)據(jù)算成不重疊的二維坐標(biāo)、把節(jié)點(diǎn)和連線畫到頁(yè)面上、把用戶的拖拽和編輯動(dòng)作反向同步回?cái)?shù)據(jù)。聽起來(lái)不復(fù)雜但真做起來(lái)布局算法、渲染方式、輸入法兼容、大數(shù)據(jù)量性能每一項(xiàng)都能卡住人半天。這篇文章適合三類人看一是前端同學(xué)接到做個(gè)腦圖功能的需求不知道怎么選型二是產(chǎn)品和技術(shù)負(fù)責(zé)人想評(píng)估是自研還是上插件三是做在線教育、知識(shí)管理、項(xiàng)目管理工具的開發(fā)者需要一張能嵌入現(xiàn)有系統(tǒng)的可編輯腦圖。我不打算給你列一堆官網(wǎng)鏈接就完事而是把主流插件的差異、落地的完整代碼、以及那些文檔里不會(huì)寫的坑一條條攤開講。1.1 三個(gè)真實(shí)場(chǎng)景決定了三種不同選型先別急著看庫(kù)先看你的場(chǎng)景長(zhǎng)什么樣。我把見過(guò)的需求歸成三類每一類的技術(shù)優(yōu)先級(jí)完全不同。第一類是只讀展示型。比如課程詳情頁(yè)里展示一張知識(shí)結(jié)構(gòu)圖用戶只能看、能縮放、能點(diǎn)擊節(jié)點(diǎn)跳轉(zhuǎn)不能編輯。這種場(chǎng)景下包體積和首屏速度是第一優(yōu)先級(jí)布局穩(wěn)定是第二優(yōu)先級(jí)。我的建議是直接用最輕的渲染方案甚至可以在構(gòu)建期就把布局算好、把坐標(biāo)寫進(jìn) JSON前端只負(fù)責(zé)畫線和定位 DOM連布局庫(kù)都能省掉。第二類是輕量編輯型。比如個(gè)人筆記工具、簡(jiǎn)易的會(huì)議記錄腦圖。用戶需要雙擊改文字、按 Tab 加子節(jié)點(diǎn)、拖拽調(diào)整層級(jí)。這類場(chǎng)景對(duì)交互手感要求很高插件必須自帶鍵盤操作和節(jié)點(diǎn)編輯能力否則你要自己實(shí)現(xiàn) contenteditable 的全套邏輯工作量翻三倍。第三類是重度協(xié)作型。多人在線、實(shí)時(shí)同步、歷史版本、權(quán)限控制全都要。這類場(chǎng)景下你選的其實(shí)是數(shù)據(jù)層方案圖形庫(kù)只是表皮。我的經(jīng)驗(yàn)是數(shù)據(jù)層用 CRDT 或者操作日志圖形庫(kù)挑一個(gè)數(shù)據(jù)模型干凈、能接受外部數(shù)據(jù)覆蓋的即可千萬(wàn)別選那種把狀態(tài)全鎖在自己內(nèi)部、外部很難干預(yù)的插件。提示先畫一張場(chǎng)景-優(yōu)先級(jí)對(duì)照表再選型比你直接去 GitHub 搜 star 數(shù)靠譜得多。很多團(tuán)隊(duì)翻車就翻在用只讀庫(kù)硬做編輯器或者用重型編輯器做只讀展示。1.2 為什么純前端方案值得優(yōu)先考慮有人會(huì)問為什么不用桌面端思維導(dǎo)圖軟件導(dǎo)出圖片嵌進(jìn)去原因很實(shí)際數(shù)據(jù)在你自己手里。用戶在哪臺(tái)設(shè)備上打開、用手機(jī)還是電腦、要不要嵌進(jìn)微信內(nèi)打開的 H5 頁(yè)面這些都不由你控制。純 HTML5 方案的好處是同一份 JSON 數(shù)據(jù)在 PC 端可以鋪開成橫向腦圖在手機(jī)端可以折疊成縱向大綱甚至降級(jí)成純文本列表一套數(shù)據(jù)多種呈現(xiàn)。另外是迭代成本。腦圖這種可視化組件產(chǎn)品經(jīng)理看一眼就會(huì)提節(jié)點(diǎn)能不能圓角一點(diǎn)連線能不能換成曲線根節(jié)點(diǎn)能不能居中這類需求。純前端方案改一個(gè) CSS 變量或者一個(gè)配置參數(shù)就完事而圖片方案每次都要回到設(shè)計(jì)工具重新導(dǎo)出。做得久了你會(huì)發(fā)現(xiàn)可配置性本身就是生產(chǎn)力。2. 主流 HTML5 思維腦圖插件橫向拆解我把手上用過(guò)、或者認(rèn)真讀過(guò)源碼的幾個(gè)方案拉出來(lái)對(duì)比。說(shuō)明一下下面的結(jié)論基于我實(shí)際使用的版本和當(dāng)時(shí)的項(xiàng)目環(huán)境不同版本差異可能不小你落地前還是要去倉(cāng)庫(kù)看一眼最近的更新記錄。插件渲染方式數(shù)據(jù)模型編輯能力包體積量級(jí)適合場(chǎng)景jsMind節(jié)點(diǎn) DOM 連線 Canvas/SVG純 JSON 樹格式清晰中等需自己補(bǔ) UI小展示為主、輕度編輯mind-elixirWeb Component DOMnodeData 樹強(qiáng)自帶工具欄和快捷鍵中開箱即用的編輯器KityMinder CoreSVG依賴 kityJSON 樹強(qiáng)但維護(hù)停滯中偏大老項(xiàng)目改造、功能對(duì)齊simple-mind-mapSVGJSON 樹強(qiáng)功能全面中偏大Vue 技術(shù)棧、復(fù)雜編輯markmapSVGd3Markdown 轉(zhuǎn)樹只讀小文檔轉(zhuǎn)腦圖、博客G6 / X6 布局包Canvas / SVG圖數(shù)據(jù)需自建大腦圖只是眾多圖之一2.1 jsMind數(shù)據(jù)干凈、改造空間大jsMind 是我個(gè)人最常推薦給新項(xiàng)目的方案理由只有一條它的數(shù)據(jù)模型干凈到不像話。一棵樹就是{id, topic, children}的遞歸結(jié)構(gòu)沒有任何框架綁定沒有隱藏狀態(tài)你從后端拿到什么就能直接喂給它導(dǎo)出也是同一個(gè)結(jié)構(gòu)。這意味著你的數(shù)據(jù)庫(kù)存的就是這份 JSON中間不需要任何轉(zhuǎn)換層。它的渲染策略是節(jié)點(diǎn)用 DOM 元素承載、連線用 Canvas 或 SVG 繪制。這個(gè)組合的好處是文字選中、復(fù)制、無(wú)障礙閱讀屬性都能直接用瀏覽器原生能力壞處是節(jié)點(diǎn)數(shù)量上去以后 DOM 節(jié)點(diǎn)會(huì)很多。我實(shí)測(cè)在一個(gè)頁(yè)面里放 3000 個(gè)節(jié)點(diǎn)滾動(dòng)和縮放開始有明顯掉幀控制在 800 到 1500 個(gè)節(jié)點(diǎn)之間體驗(yàn)就很順。另一個(gè)加分項(xiàng)是它的主題體系。它把配色抽象成 theme 對(duì)象節(jié)點(diǎn)背景、連線顏色、根節(jié)點(diǎn)樣式都在這一個(gè)對(duì)象里你想換成公司品牌色改幾行配置就行不用動(dòng) CSS 文件。對(duì)于需要跟設(shè)計(jì)規(guī)范對(duì)齊的項(xiàng)目這一點(diǎn)省事很多。當(dāng)然它也有明顯的短板編輯端的 UI 全要你自己搭。雙擊編輯、右鍵菜單、拖拽換父節(jié)點(diǎn)這些 jsMind 只給你數(shù)據(jù)層 API 和事件界面得自己寫。如果你的需求是給用戶一個(gè)完整的腦圖工具那前端工作量得按兩周起估。2.2 mind-elixir介于庫(kù)和成品之間如果不想自己搭 UI又想保留一定的定制空間mind-elixir 是個(gè)很好的中間選項(xiàng)。它基于 Web Component 實(shí)現(xiàn)這意味著你可以把它直接塞進(jìn) Vue、React 或者一份靜態(tài) HTML 里不用擔(dān)心框架沖突。它自帶的東西相當(dāng)多右鍵菜單、工具欄、鍵盤快捷鍵、節(jié)點(diǎn)拖拽、方向切換、導(dǎo)出圖片。開箱即用的程度是我用過(guò)的一批里最高的。數(shù)據(jù)結(jié)構(gòu)也不復(fù)雜一個(gè)nodeData樹字段是id、topic、children還帶expanded、direction這類控制字段語(yǔ)義很直觀。需要留意的是它的樣式隔離。Web Component 的 Shadow DOM 幫你隔離了樣式?jīng)_突但也意味著你從外部改內(nèi)部樣式會(huì)比較別扭得靠 CSS 變量或者::part選擇器。我在一個(gè)需要深度定制的項(xiàng)目里就吃過(guò)這個(gè)虧設(shè)計(jì)師給的稿子要求節(jié)點(diǎn)帶漸變邊框和自定義角標(biāo)最后是用它暴露的 CSS 變量硬湊出來(lái)的過(guò)程中反復(fù)試驗(yàn)了好幾輪。2.3 KityMinder Core功能齊但年代感明顯KityMinder 是百度前端團(tuán)隊(duì)的老作品功能覆蓋面在當(dāng)年相當(dāng)完整多種結(jié)構(gòu)邏輯結(jié)構(gòu)圖、思維導(dǎo)圖、組織結(jié)構(gòu)圖、主題切換、快捷鍵完備、導(dǎo)出 PNG 和 SVG。百度腦圖就是基于它做的所以它的成熟度不用懷疑。問題在于維護(hù)狀態(tài)。這套東西依賴自家的 kity 圖形庫(kù)而 kity 本身已經(jīng)很久沒有更新了跟現(xiàn)代構(gòu)建工具鏈配合起來(lái)有點(diǎn)別扭。我在一個(gè) Vite 項(xiàng)目里引入它的時(shí)候遇到過(guò)全局變量找不到、模塊格式不兼容的問題最后是通過(guò)配置外部依賴?yán)@過(guò)去的。如果你的項(xiàng)目是老的 webpack 體系或者你打算用 CDN 直接引腳本那問題不大如果是新項(xiàng)目我建議慎重。只在一種情況下我會(huì)推薦它你需要跟百度腦圖的數(shù)據(jù)格式對(duì)齊或者需要導(dǎo)入用戶從百度腦圖導(dǎo)出的.km文件。這種情況下它的優(yōu)勢(shì)是沒法替代的。2.4 simple-mind-mapVue 系項(xiàng)目的省心選擇這個(gè)庫(kù)作者維護(hù)得挺勤功能也在持續(xù)加。它用 SVG 渲染節(jié)點(diǎn)、連線、裝飾元素都是 SVG 元素所以放大縮小時(shí)矢量不會(huì)糊打印和高分屏表現(xiàn)都很好。它支持的結(jié)構(gòu)類型很多邏輯結(jié)構(gòu)圖、思維導(dǎo)圖、組織結(jié)構(gòu)圖、目錄組織圖、時(shí)間軸、魚骨圖都能切還內(nèi)置了豐富的主題。它的插件機(jī)制是我比較欣賞的設(shè)計(jì)。拖拽、富文本編輯、導(dǎo)出、水印、快捷鍵這些能力都是按插件掛載的你不需要的功能可以不引包體積就能壓下來(lái)。對(duì)于打包體積敏感的項(xiàng)目這個(gè)設(shè)計(jì)很實(shí)用。需要注意的是 SVG 方案的固有代價(jià)節(jié)點(diǎn)數(shù)量大了以后SVG DOM 膨脹帶來(lái)的樣式計(jì)算開銷比 Canvas 高。我測(cè)過(guò) 2000 節(jié)點(diǎn)左右的情況初次渲染和整體縮放會(huì)有可感知的延遲。如果你的數(shù)據(jù)規(guī)模會(huì)到幾千節(jié)點(diǎn)建議提前做折疊策略比如默認(rèn)只展開兩層。2.5 markmap把 Markdown 直接變成腦圖這個(gè)不算嚴(yán)格意義上的編輯器插件但對(duì)內(nèi)容創(chuàng)作者來(lái)說(shuō)價(jià)值很高。markmap 做的是把 Markdown 的標(biāo)題層級(jí)轉(zhuǎn)成樹然后渲染成可折疊的腦圖。它的渲染基于 d3出來(lái)的效果干凈利落。我的用法是把它接在博客系統(tǒng)或者文檔站點(diǎn)上給長(zhǎng)文加一個(gè)腦圖視圖切換按鈕。讀者在手機(jī)上讀長(zhǎng)文很痛苦切成腦圖就能快速抓住結(jié)構(gòu)。數(shù)據(jù)源就是原文零維護(hù)成本這個(gè)性價(jià)比很高。缺點(diǎn)是它只讀不支持拖拽編輯別指望用它做編輯器。2.6 G6 / X6腦圖只是你圖的一種如果你要做的產(chǎn)品里腦圖只是眾多圖形中的一種——比如同時(shí)還有流程圖、UML 圖、拓?fù)鋱D——那單獨(dú)引一個(gè)腦圖庫(kù)就重復(fù)了。這種情況下把 AntV 的 X6 或者 G6 當(dāng)作統(tǒng)一底座更合理。它們的布局能力是靠antv/hierarchy這個(gè)包提供的里面直接有mindmap、compactBox、dendrogram這些布局算法。你可以用同一個(gè)渲染引擎承載多種圖節(jié)點(diǎn)樣式統(tǒng)一交互統(tǒng)一維護(hù)成本反而更低。代價(jià)是你得自己實(shí)現(xiàn)腦圖特有的操作比如按 Tab 建子節(jié)點(diǎn)、按 Enter 建兄弟節(jié)點(diǎn)、折疊展開動(dòng)畫。這套東西寫下來(lái)工作量大概在兩到三周。3. 從零落地一個(gè)腦圖編輯器以 jsMind 為例光說(shuō)選型太空下面我把一個(gè)可用的腦圖編輯器從零搭出來(lái)。環(huán)境用原生 HTML ES Module不引入框架這樣你能看清每個(gè)環(huán)節(jié)在干什么?？蚣茼?xiàng)目把這套邏輯搬到組件里就行。3.1 環(huán)境準(zhǔn)備與依賴引入最省事的方式是 CDN 直引適合做原型和演示div idjsmind_container stylewidth:100%;height:600px;border:1px solid #e5e7eb;/div link relstylesheet hrefhttps://cdn.jsdelivr.net/npm/jsmind0.8/style/jsmind.css script srchttps://cdn.jsdelivr.net/npm/jsmind0.8/es6/jsmind.js/script script srchttps://cdn.jsdelivr.net/npm/jsmind0.8/es6/jsmind.draggable-node.js/script工程化項(xiàng)目建議用包管理器裝然后在業(yè)務(wù)代碼里 import。注意兩個(gè)點(diǎn)一是樣式文件必須引否則節(jié)點(diǎn)會(huì)擠成一團(tuán)因?yàn)槎ㄎ蝗磕翘?CSS二是如果要拖拽節(jié)點(diǎn)得額外引 draggable 插件主包不含這個(gè)能力。容器元素必須顯式給寬高。這一點(diǎn)看著是廢話但我見過(guò)至少三次腦圖不顯示的問題最后都是因?yàn)楦溉萜鞲叨仁?0或者用了 flex 布局但沒給min-height。3.2 數(shù)據(jù)結(jié)構(gòu)設(shè)計(jì)樹形還是扁平j(luò)sMind 支持兩種數(shù)據(jù)格式node_tree和node_array。前者是嵌套的樹后者是扁平的節(jié)點(diǎn)數(shù)組用parentid關(guān)聯(lián)。我的建議是存儲(chǔ)用樹傳輸用樹渲染也直接用樹。理由很直接腦圖的本質(zhì)就是樹用樹存最貼合語(yǔ)義也方便做遞歸操作。扁平數(shù)組的好處是查找快但腦圖的規(guī)模通常不會(huì)大到需要靠扁平化來(lái)優(yōu)化查找為了這點(diǎn)性能犧牲可讀性不劃算。一份典型數(shù)據(jù)長(zhǎng)這樣const mindData { meta: { name: 項(xiàng)目知識(shí)結(jié)構(gòu), author: demo, version: 0.1 }, format: node_tree, data: { id: root, topic: 前端知識(shí)體系, expanded: true, children: [ { id: n1, topic: HTML5, expanded: true, children: [ { id: n1-1, topic: 語(yǔ)義化標(biāo)簽, children: [] }, { id: n1-2, topic: Canvas 與 SVG, children: [] } ] }, { id: n2, topic: 工程化, expanded: true, children: [ { id: n2-1, topic: 構(gòu)建工具, children: [] }, { id: n2-2, topic: 包管理, children: [] } ] } ] } };兩個(gè)字段值得單獨(dú)說(shuō)。id必須全局唯一不能重復(fù)否則節(jié)點(diǎn)操作會(huì)錯(cuò)亂我建議在生成時(shí)就用前綴 時(shí)間戳 隨機(jī)串的方式保證唯一性別用自增數(shù)字因?yàn)槎喽送綍r(shí)自增 ID 一定會(huì)撞。expanded控制折疊狀態(tài)默認(rèn)給false會(huì)更清爽用戶點(diǎn)開哪層看哪層大數(shù)據(jù)量場(chǎng)景下這個(gè)字段能救命。3.3 初始化與核心 API 實(shí)操配置對(duì)象里最需要琢磨的是布局參數(shù)直接決定觀感const options { container: jsmind_container, editable: true, theme: primary, mode: full, // full 鋪滿容器side 只畫右側(cè) support_html: false, // 節(jié)點(diǎn)內(nèi)容是否按 HTML 解析 view: { hmargin: 100, // 畫布水平留白 vmargin: 50, // 畫布垂直留白 line_width: 2, // 連線粗細(xì) line_color: #94a3b8, draggable: true }, layout: { hspace: 32, // 同級(jí)節(jié)點(diǎn)水平間距 vspace: 18, // 同級(jí)節(jié)點(diǎn)垂直間距 pspace: 13 // 父子節(jié)點(diǎn)之間的間距 } }; const jm new jsMind(options); jm.show(mindData);hspace和vspace這兩個(gè)值別照抄。它們的合理取值跟你的字號(hào)、節(jié)點(diǎn)內(nèi)邊距強(qiáng)相關(guān)。我的經(jīng)驗(yàn)公式是垂直間距取字號(hào)乘以 1.4 左右比較舒服水平間距取節(jié)點(diǎn)平均寬度的六分之一左右。中文節(jié)點(diǎn)普遍比英文寬所以同一個(gè)設(shè)計(jì)稿在中文環(huán)境下往往要額外加 10 到 20 像素的間距不然節(jié)點(diǎn)會(huì)顯得擠。常用操作 API 我列一個(gè)速查表寫業(yè)務(wù)的時(shí)候直接查操作方法添加節(jié)點(diǎn)jm.add_node(parentNode, id, topic, direction)刪除節(jié)點(diǎn)jm.remove_node(node)修改文字jm.update_node(nodeId, topic)展開/折疊jm.expand_node(node)/jm.collapse_node(node)選中節(jié)點(diǎn)jm.select_node(node)獲取選中jm.get_selected_node()導(dǎo)出數(shù)據(jù)jm.get_data(node_tree)移動(dòng)節(jié)點(diǎn)jm.move_node(node, beforeId, parentId, direction)direction參數(shù)只有l(wèi)eft和right兩個(gè)值指的是相對(duì)根節(jié)點(diǎn)的方向。這里有個(gè)容易忽略的細(xì)節(jié)如果根節(jié)點(diǎn)有多個(gè)一級(jí)子節(jié)點(diǎn)建議左右交替分配視覺上更均衡。全堆在一邊的話畫布高度會(huì)拉得很長(zhǎng)用戶得不停滾動(dòng)。事件監(jiān)聽是編輯器的靈魂沒有它你沒法感知用戶操作jm.add_event_listener((type, data) { switch (type) { case jsMind.event_type.select: console.log(選中節(jié)點(diǎn), data.node.id); break; case jsMind.event_type.edit: console.log(節(jié)點(diǎn)被編輯, data.evt, data.node.id); break; case jsMind.event_type.show: console.log(畫布重繪完成); break; } });注意edit事件只告訴你某個(gè)節(jié)點(diǎn)被編輯了新內(nèi)容要從節(jié)點(diǎn)對(duì)象上取。如果你要做實(shí)時(shí)保存記得給保存動(dòng)作加防抖用戶打字過(guò)程中會(huì)觸發(fā)多次事件不做防抖的話后端會(huì)被打爆。3.4 保存、導(dǎo)出與后端對(duì)接保存邏輯我的建議是全量覆蓋 版本號(hào)不要做增量。腦圖的節(jié)點(diǎn)數(shù)量通常在幾百級(jí)別全量 JSON 也就幾十 KB壓縮后更小傳輸成本可以忽略。增量同步的復(fù)雜度會(huì)高一個(gè)數(shù)量級(jí)而且很容易因?yàn)閬G包導(dǎo)致前后端數(shù)據(jù)不一致得不償失。let saveTimer null; function scheduleSave() { clearTimeout(saveTimer); saveTimer setTimeout(async () { const payload jm.get_data(node_tree); await fetch(/api/mindmap/123, { method: PUT, headers: { Content-Type: application/json }, body: JSON.stringify({ version: currentVersion, data: payload }) }); }, 1200); }版本號(hào)是用來(lái)做樂觀鎖的。用戶 A 和用戶 B 同時(shí)打開一張圖A 先保存版本號(hào)從 1 變 2B 保存時(shí)帶著版本 1 提交后端發(fā)現(xiàn)當(dāng)前是 2直接返回沖突前端提示用戶內(nèi)容已被他人修改請(qǐng)刷新。這套機(jī)制簡(jiǎn)單但很有用能擋住絕大部分的覆蓋事故。導(dǎo)出圖片這塊官方生態(tài)里有截圖插件底層通常依賴 dom-to-image 這類把 DOM 轉(zhuǎn)成圖片的庫(kù)。這里有個(gè)必踩的坑如果腦圖里有跨域圖片或者跨域字體導(dǎo)出時(shí) Canvas 會(huì)被污染toDataURL直接拋安全錯(cuò)誤。解決辦法是給所有外部資源加crossoriginanonymous并且確保服務(wù)端返回了正確的 CORS 頭。字體的話最穩(wěn)的做法是把字體文件內(nèi)聯(lián)成 base64 或者干脆用系統(tǒng)字體。3.5 移動(dòng)端適配與手勢(shì)處理移動(dòng)端的第一個(gè)問題是尺寸。寬屏上鋪得很開的腦圖在手機(jī)上會(huì)變成一坨看不清的東西。我的處理方式是通過(guò)媒體查詢或 UA 判斷在窄屏下強(qiáng)制把mode切成side并且默認(rèn)折疊到第二層只展開根節(jié)點(diǎn)的直接子節(jié)點(diǎn)。第二個(gè)問題是手勢(shì)。腦圖需要支持單指拖動(dòng)平移、雙指捏合縮放但同時(shí)又希望頁(yè)面本身能上下滾動(dòng)這兩者會(huì)沖突。解決辦法是在容器上設(shè)置touch-action屬性并且只在用戶按在節(jié)點(diǎn)之外的空白區(qū)域時(shí)才攔截手勢(shì)#jsmind_container { touch-action: pan-y pinch-zoom; -webkit-user-select: none; user-select: none; }pan-y的意思是允許瀏覽器接管垂直方向的手勢(shì)橫向由我們自己處理。這個(gè)取值是權(quán)衡后的結(jié)果垂直方向留給頁(yè)面滾動(dòng)橫向留給畫布平移。如果設(shè)置成none用戶就沒法滑動(dòng)頁(yè)面了只能靠拖腦圖體驗(yàn)很差。還有一個(gè)細(xì)節(jié)是點(diǎn)擊延遲。老一點(diǎn)的移動(dòng)瀏覽器上click 事件有大約 300 毫秒的延遲用來(lái)等待判斷是不是雙擊。如果你自定義了手勢(shì)邏輯用pointerdown和pointerup自己判斷會(huì)更跟手。不過(guò)現(xiàn)在主流瀏覽器基本都默認(rèn)關(guān)閉了這個(gè)延遲除非頁(yè)面沒有設(shè)置 viewport meta所以優(yōu)先檢查 meta 標(biāo)簽meta nameviewport contentwidthdevice-width, initial-scale1, viewport-fitcover4. 性能優(yōu)化節(jié)點(diǎn)一多就卡的解法腦圖這個(gè)東西幾十個(gè)節(jié)點(diǎn)的時(shí)候隨便怎么實(shí)現(xiàn)都流暢上千個(gè)節(jié)點(diǎn)的時(shí)候就看真功夫了。這一節(jié)講的都是我在真實(shí)項(xiàng)目里驗(yàn)證過(guò)的優(yōu)化手段。4.1 渲染方式的選擇與代價(jià)DOM、SVG、Canvas 三條路線各自的開銷結(jié)構(gòu)完全不同理解了這個(gè)才能在遇到卡頓時(shí)知道往哪優(yōu)化。DOM 方案的優(yōu)勢(shì)是瀏覽器幫你做文字排版、換行、選中、無(wú)障礙。開銷量在樣式計(jì)算和重排上節(jié)點(diǎn)數(shù)量上千以后任何一次布局變動(dòng)都會(huì)觸發(fā)大范圍的樣式重算。而且節(jié)點(diǎn)層級(jí)深的時(shí)候CSS 選擇器的匹配也會(huì)變慢。SVG 方案的優(yōu)勢(shì)是矢量清晰、支持動(dòng)畫、可以用 CSS 控制樣式。開銷主要在兩塊一是 SVG 元素本身也會(huì)進(jìn) DOM 樹節(jié)點(diǎn)多了同樣膨脹二是路徑的渲染計(jì)算貝塞爾曲線和陰影濾鏡在低端設(shè)備上很吃性能。Canvas 方案的優(yōu)勢(shì)只有一個(gè)——快。幾百上千個(gè)節(jié)點(diǎn)畫起來(lái)毫無(wú)壓力因?yàn)樽罱K就是一幀位圖。代價(jià)是所有交互都要自己算命中檢測(cè)、文字換行、選中高亮、輸入框。文字輸入尤其麻煩Canvas 里沒法直接打字得疊一個(gè)絕對(duì)定位的 input 或 textarea 在上面。維度DOMSVGCanvas500 節(jié)點(diǎn)流暢流暢流暢2000 節(jié)點(diǎn)開始掉幀明顯延遲流暢文字輸入原生支持需代理需覆蓋元素導(dǎo)出清晰度依賴轉(zhuǎn)圖矢量清晰受 DPR 影響開發(fā)成本低中高我的選擇邏輯是編輯場(chǎng)景優(yōu)先 DOM 或 SVG因?yàn)檩斎塍w驗(yàn)值得那點(diǎn)性能代價(jià)大屏只讀展示場(chǎng)景節(jié)點(diǎn)超過(guò)兩千就考慮 Canvas。4.2 折疊優(yōu)先于優(yōu)化有一個(gè)思路我強(qiáng)烈推薦能用折疊解決的性能問題就不要用技術(shù)手段硬扛。用戶在任何時(shí)刻真正需要看的可能只有幾十個(gè)節(jié)點(diǎn)。你要做的是保證默認(rèn)視圖足夠克制而不是拼了命讓兩千個(gè)節(jié)點(diǎn)同時(shí)流暢渲染。具體做法是給節(jié)點(diǎn)加默認(rèn)折疊層級(jí)比如只展開到第三層超過(guò)的收起來(lái)。用戶點(diǎn)開才渲染點(diǎn)開的瞬間最多也就多幾十個(gè)節(jié)點(diǎn)壓力被攤平到每次點(diǎn)擊上。配合這個(gè)策略還可以做按需掛載。折疊起來(lái)的子樹如果插件本身支持不渲染不可見節(jié)點(diǎn)就白賺如果不支持可以在數(shù)據(jù)層預(yù)處理把折疊節(jié)點(diǎn)的 children 暫時(shí)剔掉展開時(shí)再補(bǔ)回去。這個(gè)操作要小心容易跟撤銷重做邏輯打架建議只在純展示場(chǎng)景用。4.3 重繪節(jié)流與布局算法調(diào)參布局計(jì)算本身是遞歸的復(fù)雜度大致是 O(n)。但真正拖慢體驗(yàn)的不是布局計(jì)算而是計(jì)算完之后的 DOM 更新。用戶拖動(dòng)畫布平移的時(shí)候如果每一幀都重新算布局那就是純粹的浪費(fèi)。let rafId null; function requestRender() { if (rafId) return; rafId requestAnimationFrame(() { rafId null; jm.resize(); jm.layout(); }); }用requestAnimationFrame把連續(xù)的重繪請(qǐng)求合并成每幀一次這個(gè)改動(dòng)在拖拽場(chǎng)景下提升很明顯。我實(shí)測(cè)過(guò)不加節(jié)流時(shí)拖拽一個(gè) 800 節(jié)點(diǎn)的圖幀率在 25 到 35 之間抖加上之后能穩(wěn)定在 55 以上。布局參數(shù)方面除了前面說(shuō)的間距還有個(gè)容易被忽略的是連線形式。直線段的繪制開銷遠(yuǎn)小于貝塞爾曲線曲線越復(fù)雜路徑點(diǎn)數(shù)越多。如果性能吃緊把連線降級(jí)成直線段或者簡(jiǎn)單的兩段折線視覺上損失不大性能收益很直接。實(shí)操心得別一上來(lái)就優(yōu)化。先在真實(shí)數(shù)據(jù)規(guī)模下測(cè)一遍用 Performance 面板錄一段看清楚時(shí)間花在布局計(jì)算、樣式重排還是繪制上再對(duì)癥下藥。我見過(guò)太多團(tuán)隊(duì)先花兩周做了 Canvas 重寫結(jié)果發(fā)現(xiàn)瓶頸其實(shí)是一個(gè)用了box-shadow的節(jié)點(diǎn)樣式。5. 常見坑與排查速查表這部分是純經(jīng)驗(yàn)都是我或者同事在真實(shí)項(xiàng)目里撞過(guò)的按發(fā)生頻率排。5.1 高頻問題速查現(xiàn)象大概率原因處理方式腦圖完全空白容器寬高為 0給容器設(shè)置明確高度或 min-height節(jié)點(diǎn)擠在一起樣式文件未引入補(bǔ)上插件的 CSS 引用文字改不了節(jié)點(diǎn)是只讀渲染開啟 editable 或掛載編輯插件中文輸入斷字未處理輸入法組合事件監(jiān)聽 compositionstart/end 屏蔽中間態(tài)導(dǎo)出圖片報(bào)錯(cuò)Canvas 被跨域資源污染資源加 crossorigin 或改為內(nèi)聯(lián)縮放后模糊Canvas 未按 DPR 縮放按 devicePixelRatio 放大畫布再 scale移動(dòng)端滑不動(dòng)頁(yè)面touch-action 設(shè)成了 none改為 pan-y pinch-zoom提交時(shí)數(shù)據(jù)覆蓋無(wú)版本控制加樂觀鎖沖突時(shí)提示刷新數(shù)據(jù)順序錯(cuò)亂節(jié)點(diǎn) id 重復(fù)改用全局唯一 id 生成規(guī)則首次加載很慢默認(rèn)展開了全部層級(jí)默認(rèn)只展開兩到三層5.2 中文輸入法這個(gè)坑單獨(dú)說(shuō)這個(gè)坑值得單獨(dú)拎出來(lái)因?yàn)樗[蔽了。腦圖節(jié)點(diǎn)的編輯通常是靠 contenteditable 實(shí)現(xiàn)的用戶在用拼音輸入法打字時(shí)瀏覽器會(huì)先插入拼音字母再在選詞后替換成漢字。如果你在input事件里直接同步數(shù)據(jù)、然后重新渲染節(jié)點(diǎn)拼音字母會(huì)被當(dāng)成最終內(nèi)容寫進(jìn)去用戶選完詞以后文字就亂了或者光標(biāo)直接跳到開頭。正確做法是維護(hù)一個(gè)輸入狀態(tài)標(biāo)記let composing false; const el document.querySelector(.node-edit); el.addEventListener(compositionstart, () { composing true; }); el.addEventListener(compositionend, () { composing false; syncToData(el.textContent); // 只在組合結(jié)束后同步一次 }); el.addEventListener(input, () { if (composing) return; // 組合過(guò)程中不同步 syncToData(el.textContent); });判斷是否處于組合狀態(tài)還有一個(gè)兼容寫法就是檢查事件的isComposing屬性但老版本瀏覽器支持不全用上面這套標(biāo)記法最穩(wěn)。這個(gè)坑我在三個(gè)不同項(xiàng)目里都遇到過(guò)每次都是查半天才想起來(lái)。5.3 節(jié)點(diǎn)寬度測(cè)量陷阱另一個(gè)高頻踩坑點(diǎn)是節(jié)點(diǎn)寬度。很多布局算法需要知道每個(gè)節(jié)點(diǎn)占多寬才能算間距、防止重疊。而 DOM 元素的offsetWidth在元素還沒掛到文檔里的時(shí)候是 0。解決辦法有兩個(gè)。一是先把節(jié)點(diǎn)以visibility: hidden掛上去量完寬高再?zèng)Q定最終位置代價(jià)是多一次重排。二是用 Canvas 的measureText做離線測(cè)量速度快但要自己處理?yè)Q行邏輯中英文混排、標(biāo)點(diǎn)不能出現(xiàn)在行首這些規(guī)則都得自己實(shí)現(xiàn)工作量不小。我的選擇是節(jié)點(diǎn)數(shù)量在 500 以內(nèi)直接用第一種簡(jiǎn)單可靠超過(guò) 500 且需要頻繁重算布局才上measureText并且把測(cè)量結(jié)果緩存在節(jié)點(diǎn)對(duì)象上同一個(gè)文本不重復(fù)測(cè)。6. 進(jìn)階玩法讓腦圖長(zhǎng)在業(yè)務(wù)里把腦圖跑起來(lái)只是第一步真正讓它在產(chǎn)品里有價(jià)值靠的是跟業(yè)務(wù)數(shù)據(jù)的打通。6.1 與大綱和 Markdown 雙向同步腦圖和大綱本質(zhì)上是同一份數(shù)據(jù)的兩種視圖。用戶可能喜歡用腦圖來(lái)發(fā)散但用大綱來(lái)整理。做雙向同步的關(guān)鍵是保持一個(gè)單一數(shù)據(jù)源兩個(gè)視圖都是從這份數(shù)據(jù)派生出來(lái)的渲染結(jié)果而不是各自維護(hù)一份狀態(tài)。實(shí)現(xiàn)時(shí)的核心是一個(gè)轉(zhuǎn)換函數(shù)縮進(jìn)層級(jí)對(duì)應(yīng)樹的深度標(biāo)題級(jí)別對(duì)應(yīng)層級(jí)。Markdown 轉(zhuǎn)樹的時(shí)候要注意同一級(jí)別下如果層級(jí)跳躍比如從 h1 直接跳到 h3要按掛到最近的高級(jí)別下面來(lái)處理而不是報(bào)錯(cuò)。反過(guò)來(lái)樹轉(zhuǎn) Markdown 就簡(jiǎn)單了深度加井號(hào)即可。function treeToMarkdown(node, depth 0) { const prefix #.repeat(Math.min(depth 1, 6)); let md ${prefix} ${node.topic}\n\n; (node.children || []).forEach(child { md treeToMarkdown(child, depth 1); }); return md; }有了這個(gè)能力你就可以給用戶提供導(dǎo)入 Markdown 生成腦圖和導(dǎo)出為 Markdown兩個(gè)入口。我做過(guò)的一個(gè)筆記工具里這兩個(gè)入口的使用率高得超出預(yù)期很多人就是靠它把零散筆記整理成結(jié)構(gòu)的。6.2 快捷鍵體系的設(shè)計(jì)編輯器的效率天花板取決于快捷鍵。我的建議是至少要覆蓋這幾個(gè)Tab 新建子節(jié)點(diǎn)、Enter 新建兄弟節(jié)點(diǎn)、Delete 刪除節(jié)點(diǎn)、方向鍵切換選中、空格進(jìn)入編輯、Esc 取消編輯、Ctrl/Cmd Z 撤銷。設(shè)計(jì)的時(shí)候有兩個(gè)細(xì)節(jié)要注意。一是 Tab 鍵會(huì)搶走瀏覽器默認(rèn)的焦點(diǎn)切換所以必須preventDefault但只在腦圖容器獲得焦點(diǎn)時(shí)才攔截否則會(huì)破壞頁(yè)面上其他表單的可用性。二是 Enter 鍵的語(yǔ)義要跟用戶直覺一致如果當(dāng)前處于編輯狀態(tài)Enter 應(yīng)該是結(jié)束編輯而不是新建兄弟節(jié)點(diǎn)。這兩個(gè)狀態(tài)要用一個(gè)標(biāo)志位區(qū)分清楚我見過(guò)不少實(shí)現(xiàn)把這兩件事搞混導(dǎo)致用戶打完字一按回車就多出來(lái)一個(gè)空節(jié)點(diǎn)。撤銷重做這塊如果插件本身不帶就需要你自己維護(hù)一個(gè)操作棧。棧里存的應(yīng)該是可逆操作比如{type: add, nodeId, parentId, index}和{type: remove, nodeId, snapshot}。刪除操作要把整棵子樹快照存下來(lái)不然撤銷不回去。棧的深度建議限制在 50 步以內(nèi)再多了內(nèi)存占用不劃算用戶也很少往回退那么多步。6.3 打印與導(dǎo)出導(dǎo)出場(chǎng)景主要有三種導(dǎo)出圖片、導(dǎo)出結(jié)構(gòu)化數(shù)據(jù)、打印。圖片前面說(shuō)過(guò)了重點(diǎn)講講打印。打印腦圖是個(gè)有意思的問題因?yàn)槟X圖通常比一頁(yè)紙寬得多。我的處理方式是提供一個(gè)打印視圖在這個(gè)視圖里把腦圖的高度限制放開、寬度壓到紙張寬度以內(nèi)、字號(hào)統(tǒng)一縮小、背景改成白色。用media print媒體查詢來(lái)做media print { #jsmind_container { width: 100% !important; height: auto !important; transform: scale(0.6); transform-origin: top left; } .toolbar, .context-menu { display: none !important; } }縮放系數(shù)要根據(jù)實(shí)際內(nèi)容寬度動(dòng)態(tài)算固定 0.6 只是示例。我一般會(huì)先量出腦圖的完整寬度然后除以 A4 橫向的可用寬度得到一個(gè)比例再用這個(gè)比例去設(shè)置 transform。這樣無(wú)論內(nèi)容多寬都能保證打印時(shí)塞進(jìn)一頁(yè)。還有一個(gè)細(xì)節(jié)是打印時(shí)的連線顏色。屏幕上看很淡的灰色連線打印出來(lái)會(huì)變成幾乎看不見的淺灰因?yàn)榇蛴C(jī)的墨點(diǎn)覆蓋率有限。建議在打印樣式里把連線顏色加深到 #666 或者更暗節(jié)點(diǎn)邊框加粗到 1px 以上。我在實(shí)際使用中的體會(huì)是腦圖這類工具的成敗八成取決于前期的數(shù)據(jù)模型設(shè)計(jì)兩成取決于渲染庫(kù)選得對(duì)不對(duì)。數(shù)據(jù)模型設(shè)計(jì)得干凈后面換渲染庫(kù)、加協(xié)作、加導(dǎo)出都只是替換一個(gè)渲染層的事數(shù)據(jù)模型設(shè)計(jì)得混亂等你想加新功能的時(shí)候會(huì)發(fā)現(xiàn)每個(gè)改動(dòng)都會(huì)牽動(dòng)一大片。所以寧可花半天時(shí)間把樹結(jié)構(gòu)、id 生成規(guī)則、版本控制策略這三件事想明白也別急著寫渲染代碼。最后再分享一個(gè)小技巧如果你的用戶量不大別急著上服務(wù)端存儲(chǔ)先用 localStorage 加一份導(dǎo)出 JSON 的按鈕。我見過(guò)好幾個(gè)項(xiàng)目在驗(yàn)證階段就搭了一套完整的后端結(jié)果需求變了后端全白寫。先讓用戶用起來(lái)看他們真的需要分享和協(xié)作再補(bǔ)后端也不遲。