diagram-design這個詞前端圈子里應(yīng)該不陌生——你接手過一個流程編輯器、架構(gòu)可視化工具、邏輯編排平臺或者哪怕只是臨時給業(yè)務(wù)方搭一個拖拽畫布都會發(fā)現(xiàn)一個尷尬的事實圖表設(shè)計這事表面看就是畫幾個框、連幾條線但真正做起來數(shù)據(jù)建模、渲染方案、交互細節(jié)、性能優(yōu)化每一項都能折騰掉好幾個版本。這個項目名雖然短但它背后不是一個簡單的畫布Demo而是一整套結(jié)構(gòu)化圖形的可視化編輯基礎(chǔ)設(shè)施。這篇文章我就拿真實項目中做的圖表設(shè)計器來聊從需求拆解、技術(shù)選型到核心模塊的代碼實現(xiàn)和問題排查把能落地的經(jīng)驗一次講透。1. 項目到底要干什么拆解diagram-design的核心需求1.1 圖表設(shè)計器不只是畫布很多第一次接觸這類項目的人會理解偏以為圖表設(shè)計器就是個可拖拽的繪圖白板。實際不是。圖表設(shè)計器解決的核心命題是讓用戶用圖形化的方式編輯一份嚴(yán)格的結(jié)構(gòu)化數(shù)據(jù)。打個比方。畫布是表象數(shù)據(jù)模型才是內(nèi)功。用戶在畫布上拖一個節(jié)點、連一根線本質(zhì)是在改一份類似 JSON 的圖結(jié)構(gòu)節(jié)點有哪些、連線的起點終點在哪、每個節(jié)點帶什么業(yè)務(wù)屬性。而一個合格的 diagram-designer 必須保證兩件事所見即所得畫布上的位置、連線、樣式能無損映射回數(shù)據(jù)模型可恢復(fù)、可流轉(zhuǎn)數(shù)據(jù)可以導(dǎo)出、導(dǎo)入換個渲染器也能還原出同樣的圖。我記得在模擬項目X里一開始需求方一直強調(diào)要好看、要流暢團隊差點就往畫圖工具的方向跑偏了。后來我硬是拉著業(yè)務(wù)方過了一遍真正的使用閉環(huán)——從創(chuàng)建節(jié)點、設(shè)置屬性、連接關(guān)系、導(dǎo)出結(jié)構(gòu)化配置他們才意識到自己需要的不是畫板而是一個可視化的圖編輯器。這個認(rèn)知對齊非常關(guān)鍵直接決定了后面所有技術(shù)方向。1.2 核心功能清單與優(yōu)先級排序不同場景下的 diagram-design 需求差異很大做流程圖編輯器和做網(wǎng)絡(luò)拓?fù)淇梢暬m然都叫圖表設(shè)計器重點完全不同。結(jié)合通用情況我把核心功能按優(yōu)先級排一下優(yōu)先級功能模塊說明P0畫布基礎(chǔ)節(jié)點渲染、拖拽、縮放、平移這是地基沒有它一切都免談P0節(jié)點與連線創(chuàng)建/刪除節(jié)點設(shè)置連線起點終點支持連線樣式配置P0數(shù)據(jù)導(dǎo)入導(dǎo)出至少支持 JSON 序列化/反序列化保證圖數(shù)據(jù)可保存可恢復(fù)P1對齊輔助參考線、吸附、自動對齊批量操作效率全靠這個P1撤銷重做用戶操作錯了要能回退這是編輯器區(qū)別于畫板的核心標(biāo)志P2布局算法自動排版功能比如樹形布局、分層布局復(fù)雜圖必備P2小地圖圖大了以后定位用的一般放到后期做這里多說一句優(yōu)先級順序直接影響架構(gòu)設(shè)計。如果上來就做布局算法、小地圖把架構(gòu)搞得特別重反而拖慢核心鏈路的推進。我見過不少團隊一上來就往畫布里塞多選、框選、自動布局、版本歷史結(jié)果拖到最后連基礎(chǔ)的節(jié)點拖拽都有 bug。正確的姿勢是先打通數(shù)據(jù)—渲染—編輯—導(dǎo)出這條主鏈路再往上面加輔助特性。2. 技術(shù)選型自研還是用現(xiàn)成庫怎么選才對2.1 自研 or 第三方庫沒有標(biāo)準(zhǔn)答案只要做圖表設(shè)計器第一個問題就是能不能直接用現(xiàn)成庫。市面上的方案我不一一列舉簡單分成三類完全自研、基于通用渲染庫封裝、直接基于完整圖編輯器框架。完全自研所有渲染、交互、數(shù)據(jù)都由自己實現(xiàn)。優(yōu)點是完全可控、不依賴第三方框架體積和性能都能做到極致缺點是工作量大光是一個拖拽的精細度比如縮放后坐標(biāo)修正、吸附算法就夠調(diào)一陣子的?；谕ㄓ娩秩編旆庋b比如用 SVG 或用 Canvas 渲染庫做底層業(yè)務(wù)邏輯和交互自己寫。靈活性高工作量適中這是大多數(shù)項目的務(wù)實之選。直接套完整編輯器框架優(yōu)點是功能全、開箱即用缺點是定制深了會很痛苦框架的抽象一旦和業(yè)務(wù)模型不一致改起來比自己寫還難受。我在某公司的項目里就吃過直接套框架的虧。當(dāng)時團隊為了省時間引入了一個完整的圖編輯器框架結(jié)果業(yè)務(wù)方要求節(jié)點必須是多層嵌套的復(fù)合形狀且內(nèi)嵌表單要實時聯(lián)動。框架的節(jié)點模型根本撐不住最后硬改框架源碼維護成本爆炸。后來重做時干脆基于 SVG 自己搭了一套反而清爽得多。經(jīng)驗之談如果業(yè)務(wù)里的圖結(jié)構(gòu)是規(guī)規(guī)矩矩的流程節(jié)點、連線成熟框架能省很多事但如果你的圖有特殊的交互、復(fù)合節(jié)點、自定義業(yè)務(wù)編排自研的靈活度和可控性是框架給不了的。我接觸過的diagram-design類項目絕大多數(shù)走到后期都是自研或半自研。2.2 渲染方案SVG 還是 Canvas這是繞不過去的技術(shù)決策。兩者特點我整理成一張表維度SVGCanvas渲染方式矢量 DOM 元素位圖繪制節(jié)點數(shù)量幾百個量級還能撐再多就卡上萬個也能流暢刷新交互能力每個元素都是 DOM天然支持事件需要自己做命中檢測、事件管理樣式控制CSS 隨便寫樣式靈活樣式靠繪制代碼控制縮放清晰度矢量無限清晰按像素繪制縮放可能模糊開發(fā)效率心智簡單適合編輯器復(fù)雜度高一點適合高刷場景我的判斷是做圖編輯器默認(rèn)選 SVG。原因很簡單編輯器最核心的是人和元素的交互——節(jié)點要被選中、拖動、高亮、彈菜單SVG 天然用 DOM 支持這些鼠標(biāo)事件、鍵盤事件、樣式切換都是現(xiàn)成的。數(shù)據(jù)量很大時比如超過大幾百上千個節(jié)點再考慮 Canvas 或者 Canvas 虛擬化方案。當(dāng)然如果你做的是實時監(jiān)控大屏這種以展示為主、節(jié)點多到爆的場景Canvas 是更合理的。但 diagram-design 的重點是設(shè)計而不是展示這個定位想清楚渲染方案自然就有答案了。2.3 數(shù)據(jù)模型一切交互的中樞圖表設(shè)計器的數(shù)據(jù)模型我建議遵循一個根節(jié)點 兩層結(jié)構(gòu)的設(shè)計思路Graph圖整個圖表設(shè)計器的根數(shù)據(jù)包含全局的版本號、縮放平移視口信息、節(jié)點列表、連線列表Node節(jié)點代表一個可編輯的元素。除了唯一 id 和 position / size 這些幾何信息還要有一個 data 字段用來存業(yè)務(wù)自定義數(shù)據(jù)Edge連線代表節(jié)點和節(jié)點之間的連接關(guān)系。關(guān)鍵是它必須記錄從哪個節(jié)點的哪個端口到哪個節(jié)點的哪個端口。數(shù)據(jù)模型設(shè)計得好不好直接決定后面回退、聯(lián)動、序列化的復(fù)雜度。我后來的做法是讓所有數(shù)據(jù)都掛在根對象上用統(tǒng)一的狀態(tài)容器管理任何一次操作都通過生成新狀態(tài)來驅(qū)動渲染。這樣一個好處是撤銷重做、多端同步、歷史記錄都變成了狀態(tài)切換的問題而不是在組件里手動改來改去。我放一個最小化的數(shù)據(jù)模型示意TypeScript 風(fēng)格interface DiagramData { version: number; viewport: { x: number; y: number; zoom: number; }; nodes: NodeData[]; edges: EdgeData[]; } interface NodeData { id: string; type: string; x: number; y: number; width: number; height: number; data?: Recordstring, unknown; } interface EdgeData { id: string; source: string; // 源節(jié)點 id sourcePort?: string; // 源端口 id target: string; // 目標(biāo)節(jié)點 id targetPort?: string; label?: string; }在實際項目中我看到不少團隊為了省事直接把節(jié)點坐標(biāo)、樣式、業(yè)務(wù)數(shù)據(jù)混在一起也不抽象 Graph。前期看著還行一旦要做選中、框選、屬性面板聯(lián)動、序列化就發(fā)現(xiàn)到處在打補丁。建議一開始就把數(shù)據(jù)模型當(dāng)數(shù)據(jù)庫表來設(shè)計每個字段職責(zé)單一后面會少掉大量重構(gòu)成本。3. 核心模塊實現(xiàn)要點從畫布到節(jié)點到連線3.1 畫布基礎(chǔ)坐標(biāo)系與視圖變換畫布的第一個門檻是坐標(biāo)系。屏幕上呈現(xiàn)的內(nèi)容和用戶操作時拿到的鼠標(biāo)坐標(biāo)通常不在一套坐標(biāo)系里。我一般把坐標(biāo)系分成兩層世界坐標(biāo)系圖表元素真實使用的坐標(biāo)系。節(jié)點存的 x/y 是世界坐標(biāo)和縮放無關(guān)屏幕坐標(biāo)系用戶看到的坐標(biāo)系。它等于世界坐標(biāo)乘以縮放倍率再加平移偏移。畫布放大縮小時節(jié)點的世界坐標(biāo)不要變只更新 viewport 里的 zoom 和 x/y 偏移。鼠標(biāo)事件給的是屏幕坐標(biāo)要轉(zhuǎn)換到世界坐標(biāo)再去做命中、拖拽計算。轉(zhuǎn)換公式很簡單const worldX (screenX - viewport.x) / viewport.zoom; const worldY (screenY - viewport.y) / viewport.zoom;這個基礎(chǔ)卻極容易踩坑。我遇到過一個經(jīng)典的 bug拖動節(jié)點時節(jié)點跑到鼠標(biāo)后面越縮放偏差越大。最終定位到問題——拖拽期間混用了屏幕坐標(biāo)和世界坐標(biāo)特別是 zoom 不等于 1 的時候一加一減就出錯了。經(jīng)驗是所有落到數(shù)據(jù)模型里的坐標(biāo)統(tǒng)一存世界坐標(biāo)所有讀取鼠標(biāo)位置的代碼統(tǒng)一先轉(zhuǎn)世界坐標(biāo)再用。3.2 節(jié)點的拖拽、選中與對齊輔助節(jié)點拖拽的交互邏輯拆開其實就三步鼠標(biāo)按下節(jié)點時記錄起始世界坐標(biāo)和節(jié)點的起始位置鼠標(biāo)移動時用當(dāng)前世界坐標(biāo)減去起始點得到偏移量更新節(jié)點位置鼠標(biāo)抬起時觸發(fā)一次快照更新供撤銷重做使用。但真實的拖拽體驗遠沒有這么簡單。要做得順手還得加兩樣?xùn)|西臨界判定鼠標(biāo)按下到移動的距離超過某個閾值比如 3px才算拖拽否則是點擊選中。不然每次點一下節(jié)點都會誤拖。對齊吸附拖節(jié)點的時候系統(tǒng)幫它跟附近節(jié)點的邊緣、中心線對齊。實現(xiàn)思路是候選對齊線離節(jié)點邊緣小于某個閾值比如 5px時直接把節(jié)點坐標(biāo)修正到對齊位置。吸附這個功能看著不起眼卻是編輯器順手不順手的分水嶺。我在項目里專門寫了個對齊線計算工具每次拖拽時找候選對齊線、計算修正量實測下來用戶的排版效率提升很明顯尤其是做流程圖和腦圖這類對齊要求高的場景。3.3 連線交互錨點、貝塞爾曲線與命中檢測連線的設(shè)計比節(jié)點復(fù)雜不少。一個完整的連線交互鏈路由三部分構(gòu)成錨點端口、連線路徑、命中檢測。錨點一般定義在節(jié)點邊緣或內(nèi)部的固定位置。連線不是從一個節(jié)點拉到一個節(jié)點就完事而是從一個錨點拉到另一個錨點。錨點模型允許同一個節(jié)點向外拉出多條線而且能區(qū)分這條線是從哪個方向出去的方便后面計算連線路徑。連線路徑的繪制我最常用的是貝塞爾曲線默認(rèn)用三次貝塞爾曲線控制點根據(jù)錨點方向和目標(biāo)位置自動計算。這么做的好處是曲線平滑美觀而且方向感強一眼能看出從哪出來、到哪進去。我給一個基于 SVG 的簡化示意// 假設(shè) source 方向朝右target 方向朝左 import React from react; export function BezierEdge({ sourceX, sourceY, targetX, targetY }) { const dx Math.abs(targetX - sourceX) * 0.5; const path M ${sourceX} ${sourceY} C ${sourceX dx} ${sourceY}, ${targetX - dx} ${targetY}, ${targetX} ${targetY}; return path d{path} stroke#8492A6 strokeWidth{1.5} fillnone /; }這種實現(xiàn)方式在可視化類項目里非常通用。要處理的情況還包括連線的 label文字標(biāo)簽、連線樣式虛線、實線、顏色、以及箭頭 marker。命中檢測是另一個坑。用戶要能點擊連線、選中連線、拖動連線改路。SVG 下path元素默認(rèn)的可點擊區(qū)域是路徑本身很窄不太容易點中。我當(dāng)時的方案是畫一條透明的寬 stroke比如strokeWidth{20}stroketransparent墊在真實路徑下面讓透明路徑來響應(yīng)點擊。這樣既保留了視覺上的細線又給了用戶友好的點擊熱區(qū)。3.4 布局算法放在什么階段做布局算法是個容易過把癮就死的功能。自動排版看起來炫酷但做好很困難。我的建議是如果項目不是以自動生成圖為核心布局算法別放在早期版本。原因很現(xiàn)實——自動布局很難滿足用戶的審美有時候排出來的圖是邏輯正確但怎么看怎么怪用戶最后還是要手動調(diào)。真正需要的場景一般是三種樹形結(jié)構(gòu)比如組織架構(gòu)圖、目錄樹。這類布局用經(jīng)典的樹形遞歸布局就能搞定從上到下逐層排同一層節(jié)點對齊。分層結(jié)構(gòu)比如流程圖、狀態(tài)機?？梢杂梅謱硬季炙惴ò压?jié)點按層級分列擺開再調(diào)整連線交叉。自由拓?fù)浔热缇W(wǎng)絡(luò)拓?fù)?、關(guān)系圖。這個比較復(fù)雜一般要上力導(dǎo)向布局模擬物理彈性、斥力、引力讓節(jié)點自動散開。如果在后期必須做一個見效快的自動排版我建議從樹形布局和分層布局入手計算公式和效果可預(yù)期也好看力導(dǎo)向布局雖然炫但參數(shù)調(diào)起來很磨人投入產(chǎn)出比要好好掂量。4. 實操記錄搭建一個最小可用的圖表設(shè)計器4.1 項目骨架與依賴準(zhǔn)備這一節(jié)我把當(dāng)初做最小可用圖表設(shè)計器的實操過程完整走一遍。技術(shù)棧我選 Vite React TypeScript加一個輕量的狀態(tài)管理庫。為什么選這套原因有兩個一是生態(tài)成熟寫交互組件方便二是類型定義完善對數(shù)據(jù)模型的約束強特別適合圖表編輯器這種數(shù)據(jù)結(jié)構(gòu)驅(qū)動的工程。項目初始化命令按當(dāng)時的推進方式大概是npm create vitelatest diagram-design-demo -- --template react-ts cd diagram-design-demo npm install npm install zustand選 Zustand 是因為它在中小型圖表編輯器里的狀態(tài)管理成本最低不需要像大型框架那樣寫一堆模板代碼同時又支持按需訂閱更新對性能友好。真實項目里我更喜歡直接用 Zustand而不是再套一層模型層因為圖表數(shù)據(jù)本身的結(jié)構(gòu)已經(jīng)足夠表達模型了沒必要再包一層。4.2 定義數(shù)據(jù)模型與狀態(tài)容器繼續(xù)往下之前先把數(shù)據(jù)模型寫進代碼。我把 Graph、Node、Edge 的類型定義和狀態(tài)初始化放一起import { create } from zustand; interface Viewport { x: number; y: number; zoom: number; } interface NodeData { id: string; type: string; x: number; y: number; width: number; height: number; data: Recordstring, unknown; } interface EdgeData { id: string; source: string; sourcePort: string; target: string; targetPort: string; } interface DiagramState { viewport: Viewport; nodes: NodeData[]; edges: EdgeData[]; selectedIds: string[]; moveNode: (id: string, dx: number, dy: number) void; } export const useDiagramStore createDiagramState((set) ({ viewport: { x: 0, y: 0, zoom: 1 }, nodes: [], edges: [], selectedIds: [], moveNode: (id, dx, dy) set((state) ({ nodes: state.nodes.map((node) node.id id ? { ...node, x: node.x dx, y: node.y dy } : node ) })) }));這里有一個關(guān)鍵點我反復(fù)提節(jié)點位置用世界坐標(biāo)存儲更新時只做加減不做縮放換算。這樣實現(xiàn)撤銷快照時最簡單至少不用每次快照前先把坐標(biāo)還原到統(tǒng)一基準(zhǔn)快照之間的數(shù)據(jù)口徑始終一致。4.3 畫布組件SVG 渲染與坐標(biāo)轉(zhuǎn)換有了數(shù)據(jù)層直接到渲染層。畫布組件負(fù)責(zé)渲染所有節(jié)點和邊、以及把鼠標(biāo)屏幕坐標(biāo)轉(zhuǎn)成世界坐標(biāo)。我當(dāng)時的實現(xiàn)如下import React, { useRef, useCallback } from react; import { useDiagramStore } from ./store; import { BezierEdge } from ./BezierEdge; export function Canvas() { const svgRef useRefSVGSVGElement(null); const viewport useDiagramStore((s) s.viewport); const nodes useDiagramStore((s) s.nodes); const edges useDiagramStore((s) s.edges); const toWorld useCallback((clientX: number, clientY: number) { const svg svgRef.current; const rect svg.getBoundingClientRect(); const screenX clientX - rect.left; const screenY clientY - rect.top; return { x: (screenX - viewport.x) / viewport.zoom, y: (screenY - viewport.y) / viewport.zoom }; }, [viewport]); const handleMouseMove (e: React.MouseEvent) { const world toWorld(e.clientX, e.clientY); console.log(world coords:, world); }; return ( svg ref{svgRef} width100% height600 style{{ background: #F7F8FA }} onMouseMove{handleMouseMove} g transform{translate(${viewport.x} ${viewport.y}) scale(${viewport.zoom})} {edges.map((edge) { const source nodes.find((n) n.id edge.source); const target nodes.find((n) n.id edge.target); if (!source || !target) return null; return ( BezierEdge key{edge.id} sourceX{source.x source.width} sourceY{source.y source.height / 2} targetX{target.x} targetY{target.y target.height / 2} / ); })} {nodes.map((node) ( g key{node.id} transform{translate(${node.x} ${node.y})} rect width{node.width} height{node.height} rx{6} fill#FFFFFF stroke#C0C4CC / text x{12} y{24} fontSize{14} fill#1F2D3D {String(node.data.label ?? node.id)} /text /g ))} /g /svg ); }這里有個容易忽略的細節(jié)g的transform用的是translate(...) scale(...)順序不能反。如果寫成scale(...) translate(...)縮放中心就從原點變掉了圖會到處亂跑。我當(dāng)時調(diào)試縮放功能時就被這個問題坑了半小時后來把這個順序固定下來并寫進注釋避免后續(xù)維護再造坑。節(jié)點拖動事件在真實項目里通常要綁定在單個節(jié)點上對rect或整個g加onMouseDown然后配合window級的mousemove/mouseup來完成拖拽。這里不貼全量代碼了但要點就一個拖拽移動的監(jiān)聽不要掛在 SVG 上而要掛在 window 上。否則鼠標(biāo)移出 SVG 邊界節(jié)點就丟了這是實戰(zhàn)中第一必踩的坑。4.4 連線交互拖線拉出一條新邊除了渲染已有的邊從節(jié)點拉一條線出來也是圖表設(shè)計器的標(biāo)志性動作。實現(xiàn)思路是開始拖拽時創(chuàng)建一個臨時邊狀態(tài)終點跟著鼠標(biāo)走松開時若落在合法錨點上則生成正式邊。簡化版的臨時邊狀態(tài)interface TempEdge { sourceId: string; sourceX: number; sourceY: number; currentX: number; currentY: number; }臨時邊渲染時用貝塞爾曲線把 source 端連到鼠標(biāo)當(dāng)前位置鼠標(biāo)松開時找到命中的節(jié)點和端口然后調(diào)用addEdge寫入正式數(shù)據(jù)。這個交互的細節(jié)在端點命中上。我當(dāng)時設(shè)計了端點的熱區(qū)概念如果鼠標(biāo)位置離某個節(jié)點的中心很近比如節(jié)點寬高的一半以內(nèi)就認(rèn)為要連接到該節(jié)點否則是空白區(qū)域取消連線。沒有一個好的熱區(qū)規(guī)則用戶拉線的時候總是差一點接上體驗會非常挫敗。這個熱區(qū)規(guī)則的調(diào)優(yōu)沒有一個萬能參數(shù)但基本思路是一致的給用戶靠近即吸附的手感。4.5 導(dǎo)入導(dǎo)出讓圖數(shù)據(jù)能保存和恢復(fù)圖表設(shè)計器做得再好數(shù)據(jù)不能導(dǎo)出就廢了一半。導(dǎo)入導(dǎo)出的兩條曲線第一JSON 導(dǎo)入導(dǎo)出。這個最簡單直接JSON.stringify(diagramData)保存導(dǎo)入時解析賦值回狀態(tài)。注意解析的時候要做數(shù)據(jù)校驗別帶一堆非法節(jié)點進來至少檢查 nodes 不是數(shù)組、id 唯一。第二圖片導(dǎo)出。很多用戶都想要導(dǎo)出 PNG。SVG 做法比 Canvas 簡單把 SVG 序列化成字符串放進Image對象然后繪制到canvas上再toDataURL下載。這里有個常見坑如果 SVG 里有外部字體導(dǎo)出時字體可能渲染不一致更常見的是內(nèi)部用了foreignObject嵌入 HTML導(dǎo)出會白屏。所以導(dǎo)出前最好確保內(nèi)容都是純矢量。我當(dāng)時做圖片導(dǎo)出時就是把內(nèi)嵌的 HTML 移除改成 SVG 原生 text 來渲染文字才解決了白屏問題。這個經(jīng)驗適用于大部分圖表設(shè)計器項目導(dǎo)出圖片前考慮 SVG 的兼容性避免依賴外部資源。4.6 快捷操作與撤銷重做快捷鍵是編輯器體驗的放大器。至少要支持 Ctrl/Cmd Z撤銷、Ctrl/Cmd C / V復(fù)制粘貼、Delete刪除選中。實現(xiàn)上不要寫給每個組件單獨建一個全局快捷鍵監(jiān)聽模塊統(tǒng)一分發(fā)。撤銷重做我推薦兩種方案對比方案思路優(yōu)點缺點快照每次操作后保存整體數(shù)據(jù)快照實現(xiàn)簡單邏輯清晰內(nèi)存消耗大節(jié)點多時頻繁快照會卡命令模式每個操作定義 undo/redo 兩個方法內(nèi)存友好操作粒度細抽象成本高每個操作要寫兩遍邏輯我實際的項目里中等復(fù)雜度圖用了快照 節(jié)流的組合只有鼠標(biāo)松開、鍵盤刪除這類操作結(jié)束時才生成快照拖拽過程中的實時移動不生成快照。這樣內(nèi)存壓力可控代碼也簡單得多。真到了圖譜特別大的場景再考慮命令模式也不遲。5. 常見問題與排查實錄把踩過的坑都攤開說5.1 圖表一多就卡頓到底卡在哪圖表設(shè)計器最常見的性能問題是節(jié)點上百個之后拖拽畫布、縮放開始掉幀交互有明顯的延遲。我排查性能問題的固定套路是三步走先確定瓶頸在渲染還是狀態(tài)。如果純 DOM 渲染卡資源面板里看 JS 執(zhí)行時間如果狀態(tài)更新頻繁導(dǎo)致大量組件重渲染就要看更新訂閱范圍。減少不必要的重渲染。用 Zustand 時每個組件按需訂閱它關(guān)心的字段別把整個 store 都放進去。這個點在 React 下特別有效。SVG 元素數(shù)量過大。幾百個節(jié)點在 SVG 里其實還好上千個就明顯吃力。此時可以選擇對離屏/不顯示的節(jié)點做懶渲染或按視口裁剪只渲染可視區(qū)域。我清楚的記得模擬項目X里節(jié)點一多畫布平移就卡后來定位到問題在所有節(jié)點都在 SVG 里常駐渲染平移時每個節(jié)點都要跟著重排。后來我把節(jié)點分組平移時只更新外層g的 transform內(nèi)層節(jié)點不動性能一下提了上來。這種靜態(tài)內(nèi)容打包成小組動態(tài)位移只動小組外層的思路特別適合 SVG 渲染的圖表編輯器。5.2 拖拽錯位坐標(biāo)換算別踩坑拖拽錯位是圖表設(shè)計器里出現(xiàn)頻率最高、也最容易讓人迷惑的問題。癥狀是拖動節(jié)點時節(jié)點明顯偏離鼠標(biāo)位置而且縮放比例越大偏得越多。我在排查這種問題時必查三處事件監(jiān)聽用的坐標(biāo)是什么如果直接用e.clientX、e.clientY這是屏幕坐標(biāo)如果用e.offsetX、e.offsetY那是相對于當(dāng)前目標(biāo)元素的坐標(biāo)。兩者都要先轉(zhuǎn)世界坐標(biāo)。節(jié)點位置和拖拽開始位置是否同一坐標(biāo)口徑節(jié)點存的是世界坐標(biāo)拖拽計算如果用屏幕坐標(biāo)加一減一加就錯位了。CSS transform 有沒有影響坐標(biāo)換算如果容器不是全屏svg.getBoundingClientRect()返回的 rect 會包含容器位置和縮放所以不要想當(dāng)然地拿clientX做減法要先減去rect.left。這個排查思路幫我在好多次 Code Review 里一針見血地發(fā)現(xiàn)問題。遇到錯位問題別急著加偏移補償先把坐標(biāo)口徑理清楚80% 的問題半小時內(nèi)就能定位。5.3 撤銷重做的幾個隱形坑撤銷重做看著簡單做起來全是細節(jié)。最典型的問題有三個撤銷后節(jié)點和連線不同步。比如節(jié)點刪了連到它的邊還在或者撤銷添加節(jié)點操作時節(jié)點沒了邊還懸空。根治辦法是操作封裝成變更集節(jié)點和受影響的邊一起進快照。撤銷時 viewport 要不要恢復(fù)用戶把一個地方放大然后撤銷編輯視圖卻跳回之前的狀態(tài)體驗很差。常規(guī)做法是視口不進撤銷快照單獨維護一個純視圖狀態(tài)。連按撤銷過快導(dǎo)致內(nèi)存爆炸。這個好解決限制快照數(shù)量比如只保留最近的 50 個快照超出就把最老的丟掉。還有一個細節(jié)特別容易忽略編輯器初始加載時不要生成快照否則用戶一進頁面按撤銷發(fā)現(xiàn)界面回到了一片空白。解決辦法是初始數(shù)據(jù)先應(yīng)用完再初始化快照棧的起點。5.4 縮放后節(jié)點位置漂移或文字模糊如果使用 SVG 渲染矢量圖形理論上不會模糊。文字模糊常常是因為用了某些外部字體、或者 SVG 嵌入了foreignObject。解決辦法是文字統(tǒng)一用 SVG text 渲染字體用系統(tǒng)字體棧。節(jié)點位置漂移的問題多半還是出在坐標(biāo)口徑或 transform 順序上。我之前調(diào)試過一個 bug縮放時節(jié)點位置看起來是飄的后來發(fā)現(xiàn)是scale寫在了translate前面縮放中心從原點變成了 0,0導(dǎo)致整個圖縮放時整體往一個方向跑。修正順序后一切恢復(fù)正常。記住transformtranslate(x y) scale(zoom)才是以 (x,y) 為錨點縮放的正確寫法。6. 一點自己的心思圖表設(shè)計器這類項目真正有價值的地方不是堆了多少炫酷功能而是把數(shù)據(jù)模型這個地基打扎實。我吃過的虧里十有八九是前期不重視數(shù)據(jù)模型后期返工補課。節(jié)點、邊、端口、視口這四類數(shù)據(jù)一開始分清楚職責(zé)邊界后面加功能都順。還有一個感受想分享做 diagram-design一定要多跟真實用戶一起操作幾輪。你真看用戶是怎么畫圖的會發(fā)現(xiàn)他們根本不關(guān)心技術(shù)選型只在乎拖得順不順、對齊準(zhǔn)不準(zhǔn)、連線好不好接、撤銷穩(wěn)不穩(wěn)。銷售說的用戶體驗就是這些看起來很不起眼的交互細節(jié)。把這些細節(jié)打磨好才是這個項目最值得投入的地方。如果你正要開始做類似的圖表設(shè)計器我的建議是先用最簡版本打通畫節(jié)點、拉連線、導(dǎo)出 JSON這條鏈路再回去填功能細節(jié)。別一上來就規(guī)劃宏偉藍圖先把一杯水倒?jié)M再考慮裝更大的壺。