先從結(jié)論說起這類名為“diagram-design”的項目核心目標從來不是“畫出好看的圖”而是“讓圖和背后的數(shù)據(jù)關(guān)系對得上”。我在實際動手做了幾個月之后最大的感受是圖表設(shè)計最難的部分不是渲染而是把數(shù)據(jù)模型、交互狀態(tài)和視覺表現(xiàn)三者解耦清楚。下面把我的完整設(shè)計與實操過程拆開講從數(shù)據(jù)建模到渲染管線再到避坑實錄都整理出來。1. 整體設(shè)計思路先想清楚“圖”到底是什么1.1 核心需求拆解在動工之前我先把這個標題翻譯成具體的功能清單。所謂“diagram-design”往細了說無非是三件事創(chuàng)建和編輯節(jié)點節(jié)點有坐標、大小、樣式可以被拖拽、縮放、刪除、復(fù)制。建立連接關(guān)系節(jié)點之間通過邊連接邊能記錄從哪里出發(fā)、到達哪里還能在中途拐彎。整體視圖控制畫布可以縮放、平移局部細節(jié)和整體結(jié)構(gòu)可以切換查看。這三件事拆完之后我發(fā)現(xiàn)真正的難點在第一件事的前半句“坐標、大小、樣式”這些數(shù)據(jù)從哪里來答案是從用戶的操作中來但操作只是表象背后必須有一份可以被持久化、被復(fù)制、被程序讀取的數(shù)據(jù)結(jié)構(gòu)。否則你畫出來的圖只能看不能存更不能參與業(yè)務(wù)邏輯判斷。我做了一個取舍所有的圖形元素都用純數(shù)據(jù)描述不把任何視覺狀態(tài)混進去。節(jié)點的位置、顏色、大小是數(shù)據(jù)節(jié)點處于“選中”“高亮”這類交互狀態(tài)則不屬于數(shù)據(jù)——它們是運行時的臨時狀態(tài)。這個分離規(guī)則在后續(xù)開發(fā)里幫我省了大量麻煩。1.2 為什么不自已從零折騰一套復(fù)雜引擎很多人一聽到圖表設(shè)計第一反應(yīng)是去引入現(xiàn)成的開源庫。這個思路沒有問題但對于我這種希望深度定制交互、并且要把圖數(shù)據(jù)導(dǎo)入導(dǎo)出到其他系統(tǒng)的場景現(xiàn)成庫反而會帶來幾層限制它的數(shù)據(jù)格式是固定的你的業(yè)務(wù)模型得遷就它它的狀態(tài)管理是內(nèi)置的你想和外部框架聯(lián)動得靠事件橋接它的自定義渲染能力再強也不可能完全覆蓋你想要的視覺規(guī)范。所以我的判斷是自研一個輕量級圖編輯器核心是值得的。這里“輕量級”三個字很重要它意味著不需要處理巨型圖、不需要復(fù)雜的動畫引擎、不需要多用戶實時協(xié)同。我的目標是支撐單畫布內(nèi)幾百個節(jié)點、上千條邊的規(guī)模同時保證交互不掉幀。這個量級下完全可以通過合理設(shè)計做到。當然如果圖規(guī)模到了上萬個節(jié)點或者需要多人同時編輯那自研的代價會急劇上升此時使用成熟的圖編輯平臺反而更劃算。取舍的關(guān)鍵指標就一個圖和你的業(yè)務(wù)數(shù)據(jù)之間耦合得有多深。1.3 技術(shù)方案選型我的技術(shù)棧定在純前端主語言用 TypeScript。選擇 TypeScript 的理由非常直接圖數(shù)據(jù)涉及大量類型定義節(jié)點類型、邊類型、端口類型在編譯期就定死比靠人腦記憶字段名靠譜得多。數(shù)據(jù)渲染層我選擇了兩套渲染方案并存畫布Canvas負責主場景渲染SVG 負責少量裝飾性元素。具體理由在后面的渲染章節(jié)詳細展開這里先給結(jié)論——Canvas 在復(fù)雜場景下性能優(yōu)勢明顯但文本適配和局部更新不如 SVG 靈活所以兩者各司其職。狀態(tài)管理方面我引入了一個簡單的狀態(tài)機維護畫布當前的模式空閑、拖拽節(jié)點中、連線中、框選中。每種模式對應(yīng)的鼠標事件處理完全不同用狀態(tài)機可以避免大量互相打架的 if-else。整體架構(gòu)分成了三層數(shù)據(jù)層節(jié)點、邊、端口的純數(shù)據(jù)模型負責增刪改查和序列化。視圖層負責將數(shù)據(jù)模型渲染到畫布并處理視口變換。交互層監(jiān)聽鼠標、鍵盤事件將其翻譯成數(shù)據(jù)層的修改操作。這個分層的核心原則是單向數(shù)據(jù)流用戶操作 → 交互層解析 → 修改數(shù)據(jù)層 → 視圖層訂閱變化并重繪。交互層不直接改畫布視圖層不反向改數(shù)據(jù)數(shù)據(jù)層不感知任何 UI 細節(jié)。2. 核心數(shù)據(jù)模型把所有圖形變成可存儲的數(shù)據(jù)2.1 節(jié)點、邊、端口的建模細節(jié)先說我經(jīng)過幾次重構(gòu)后的最終數(shù)據(jù)結(jié)構(gòu)。一張圖我用一個對象表示包含三塊interface Diagram { id: string; nodes: Mapstring, DiagramNode; edges: Mapstring, DiagramEdge; meta: DiagramMeta; } interface DiagramNode { id: string; type: string; x: number; y: number; width: number; height: number; ports: Port[]; // 連接錨點 data: Recordstring, unknown; // 業(yè)務(wù)數(shù)據(jù)不渲染但持久化 } interface Port { id: string; position: top | bottom | left | right; offset: number; // 端口在該邊上的相對位置0~1 } interface DiagramEdge { id: string; sourceNodeId: string; sourcePortId: string; targetNodeId: string; targetPortId: string; points: Point[]; // 折線的中間拐點可為空 data: Recordstring, unknown; }我公開過很多次這個數(shù)據(jù)結(jié)構(gòu)每次被問到最多的都是為什么要單獨拆出一個Port概念而不是直接用節(jié)點坐標計算連接點關(guān)鍵在于邊的連接位置必須是穩(wěn)定、可恢復(fù)的。如果一條邊連接的是“節(jié)點A的右側(cè)邊緣中間”那么無論節(jié)點A怎么移動這條邊的連接點都會跟著右側(cè)邊緣跑。如果你只存了節(jié)點的中心點每次重新計算連接點就會受節(jié)點尺寸變化影響——節(jié)點一旦改變寬高整條邊的位置就會漂移。端口這個概念的另一個好處是它天然支持“同節(jié)點多連接錨點”。一個節(jié)點可能有多個輸出口每個輸出口都是獨立的端口邊只需要記錄端口 ID 即可不需要關(guān)心端口的具體坐標。坐標由視圖層根據(jù)節(jié)點位置實時計算。2.2 數(shù)據(jù)序列化與格式兼容圖數(shù)據(jù)最終要能被保存到文件、數(shù)據(jù)庫或者發(fā)送給后端。所以序列化格式的設(shè)計非常關(guān)鍵。我用的是帶版本號的 JSON Schema{ version: 1.3.0, diagram: { id: diagram-001, meta: { title: 訂單流程圖 }, nodes: [], edges: [] } }version字段是我踩過坑之后補上的。起初我在本地開發(fā)時沒有版本號后來數(shù)據(jù)結(jié)構(gòu)調(diào)整舊數(shù)據(jù)全部無法解析幾千條測試數(shù)據(jù)直接作廢。加上版本號之后每次寫解析器都先判斷版本再決定走哪條遷移分支數(shù)據(jù)兼容的問題就徹底解決了。序列化時還應(yīng)遵循“可以丟了不致命但保留更好”的字段放最后的原則。核心節(jié)點和邊的 ID、連接關(guān)系是必須的缺了圖就廢了樣式和坐標可以恢復(fù)成默認值但保留可以提升還原度擴展字段全部掛到data對象里不占主體結(jié)構(gòu)。2.3 撤銷與重做快照策略很關(guān)鍵撤銷和重做是圖編輯器的隱形能力沒有它任何誤操作都像毀尸現(xiàn)場。我的實現(xiàn)方式是每次數(shù)據(jù)變更之前記錄上一個完整快照變更完成后記錄新快照撤銷和重做就是在這兩個快照之間切換。問題在于快照是深拷貝深拷貝的成本很高而很多操作只是一次小修改比如拖動節(jié)點拖動的過程中可能產(chǎn)生幾十次中間狀態(tài)。全量快照會讓內(nèi)存和 CPU 都吃緊。我最終采用了兩層策略拖拽、縮放這類連續(xù)操作在開始時存一份快照操作過程中產(chǎn)生的中間狀態(tài)不保存操作結(jié)束時再存一份最終快照。這樣一次拖拽永遠只對應(yīng)一次撤銷步驟。其他離散操作添加節(jié)點、刪除邊、修改顏色每次操作前存一份快照。這個方案實現(xiàn)簡單卻能把內(nèi)存占用降低一個數(shù)量級。我實測在 200 個節(jié)點的畫布上連續(xù)拖拽 10 秒撤銷棧里只新增了 2 個快照內(nèi)存波動可以忽略。3. 渲染管線的核心細節(jié)畫布為什么比想象中復(fù)雜3.1 Canvas 和 SVG 的取舍在圖表設(shè)計這個領(lǐng)域Canvas 和 SVG 的爭論從來沒有定論但我的選擇標準非常實用誰能在我的場景下用更少的代碼達到更好的交互體驗誰就上。SVG 的最大優(yōu)勢是 DOM 化每個圖形就是一個 DOM 節(jié)點可以綁定事件、修改樣式、單獨更新、配 CSS 動畫。對于節(jié)點數(shù)較少幾十到一百的圖表SVG 的開發(fā)效率明顯更高因為很多渲染細節(jié)瀏覽器幫你處理了。但當節(jié)點數(shù)上升到幾百邊數(shù)上千DOM 節(jié)點數(shù)量開始拖慢頁面。任何一個節(jié)點的重繪都可能觸發(fā)瀏覽器的樣式重算和布局更新響應(yīng)延遲會明顯變大。Canvas 沒有這個負擔所有圖形都畫在一塊畫布上沒有 DOM 節(jié)點更新時只需調(diào)用重繪函數(shù)。代價是你需要自己實現(xiàn)命中檢測、事件映射、局部更新等于瀏覽器的 DOM 能力沒法用了都得自己寫。我在項目中的最終策略是主場景用 Canvas 渲染全部節(jié)點和邊保證性能和渲染上限浮動的連接預(yù)覽線、我正在拖拽中的節(jié)點輪廓提醒這類“臨時裝飾”用 SVG 疊在畫布上層因為這類元素只存在于交互瞬間量小而靈活SVG 的語法表達更舒服。3.2 視口變換一張圖兩個坐標系圖編輯器必須支持縮放和平移這是硬需求。實現(xiàn)縮放平移的核心是理解兩套坐標系之間的換算世界坐標World Coordinates數(shù)據(jù)模型里的 x、y 是真實坐標節(jié)點之間的距離關(guān)系用世界坐標描述它不隨視口變化。屏幕坐標Screen Coordinates畫布上用戶實際看到的坐標等于世界坐標經(jīng)過平移和縮放變換之后的結(jié)果。兩者之間的換算公式簡單直接// 世界坐標 → 屏幕坐標 screenX (worldX - viewportCenterX) * zoom canvasWidth / 2; screenY (worldY - viewportCenterY) * zoom canvasHeight / 2; // 屏幕坐標 → 世界坐標用于鼠標定位 worldX (screenX - canvasWidth / 2) / zoom viewportCenterX; worldY (screenY - canvasHeight / 2) / zoom viewportCenterY;看似簡單但真做起來有兩個常見坑。第一個坑是縮放中心。用戶滾動滾輪時通常希望鼠標指向的位置在縮放后保持不動也就是“以鼠標為中心縮放”。實現(xiàn)方式是先記錄鼠標在縮放前位于哪個世界坐標縮放后把這個世界坐標重新映射回鼠標的屏幕位置從而反推出新的視口中心。公式如下const worldPointBeforeZoom screenToWorld(mouseScreenX, mouseScreenY); zoom clamp(zoom * factor, minZoom, maxZoom); // 將世界點重新投影到鼠標處反推出視口中心 viewportCenterX worldPointBeforeZoom.x - (mouseScreenX - canvasWidth / 2) / zoom; viewportCenterY worldPointBeforeZoom.y - (mouseScreenY - canvasHeight / 2) / zoom;第二個坑是縮放邊界。無限縮放會讓畫布漂到看不見的地方或者把場景縮到比一像素還小。我設(shè)置了最小 10%、最大 500% 的縮放范圍同時在實現(xiàn)上用clamp函數(shù)把計算后的 zoom 鎖死。另一個隱藏問題是縮放值如果是浮點數(shù)累計十幾次滾輪之后精度漂移會讓視圖抖動。我干脆在縮放事件里只保留兩位小數(shù)實測后用戶基本感覺不到。3.3 命中檢測與框選Canvas 渲染模式下沒有 DOM 可以點擊所有交互都要自己判斷“鼠標落在了哪個元素上”。最樸素的辦法是遍歷全部節(jié)點逐個判斷鼠標點是否落在節(jié)點矩形內(nèi)。節(jié)點數(shù)量少時這么做可以接受但節(jié)點一多每次 mousemove 都全量遍歷性能就開始露餡。我的優(yōu)化是建立一套空間索引按網(wǎng)格劃分畫布區(qū)域節(jié)點按所在網(wǎng)格注冊鼠標移動時只檢測鼠標所在網(wǎng)格及相鄰網(wǎng)格內(nèi)的節(jié)點遍歷量直接下降一個數(shù)量級。const gridSize 64; const grid new Mapstring, DiagramNode[](); function getGridKey(x: number, y: number): string { return ${Math.floor(x / gridSize)},${Math.floor(y / gridSize)}; }網(wǎng)格的鍵是坐標除以格子大小的取整結(jié)果節(jié)點插入時按其中心點所在的格子歸入對應(yīng) key。命中檢測時只查詢鼠標點所在的三個格子當前格、左側(cè)格、上側(cè)格里的節(jié)點做精確矩形判斷?？蜻x的做法類似拖拽出橡皮筋選框時遍歷受影響網(wǎng)格里的節(jié)點只要節(jié)點的矩形和選框矩形有交集就視為被選中。這里要注意的是框選時需要把屏幕坐標的選框反算成世界坐標再來判斷因為節(jié)點存儲的是世界坐標直接拿屏幕坐標去比對會因為縮放平移的干擾而錯誤。我在實際實現(xiàn)中還發(fā)現(xiàn)一個細節(jié)節(jié)點選中狀態(tài)應(yīng)顯示在渲染層之外。選中節(jié)點的邊框、陰影屬于表達層狀態(tài)直接掛在臨時狀態(tài)對象里不會污染數(shù)據(jù)模型。這樣圖數(shù)據(jù)導(dǎo)出時不會包含多余信息重開畫布時也不需要重建選中狀態(tài)。4. 實操過程從空白畫布到可交互編輯器4.1 環(huán)境準備與基礎(chǔ)依賴開始編碼之前我先明確依賴清單。這里列的是我實際用到的最小集合能少裝的絕不多裝TypeScript類型系統(tǒng)核心依賴Vite開發(fā)服務(wù)器和構(gòu)建工具主打一個快無 UI 框架純 Canvas 場景框架在這場合幫不上什么忙初始化方式非常標準npm create vitelatest diagram-design -- --template vanilla-ts cd diagram-design npm install為什么不用 Vue 或 React因為 Canvas 渲染的主場景不依賴框架的虛擬 DOM節(jié)點的增刪改全由數(shù)據(jù)層觸發(fā)重繪框架反而會引入不必要的橋接邏輯。UI 面板、屬性編輯器這些外圍組件我是寫在一個簡單的 div 層上的直接用原生事件綁定即可。4.2 核心實現(xiàn)的逐步推進我按下面這張順序表逐步推進開發(fā)每完成一步都會做一次手動測試確保沒有崩壞第一步數(shù)據(jù)模型層先寫出DiagramNode、DiagramEdge、Diagram的類型定義和增刪改查方法。這個階段不碰渲染所有操作都只是純數(shù)據(jù)變化。第二步基礎(chǔ)畫布渲染創(chuàng)建 Canvas 并畫出一批靜態(tài)節(jié)點和邊驗證整個數(shù)據(jù)到圖形的映射關(guān)系。程序跑通后我加了一個背景網(wǎng)格線方便觀察坐標位置是否正確。第三步鼠標事件接入實現(xiàn)鼠標按下、移動、釋放的事件監(jiān)聽區(qū)分左鍵和右鍵行為。切換畫布模式為拖拽模式實現(xiàn)節(jié)點跟隨鼠標移動。第四步滾輪縮放與拖拽平移把視口變換邏輯接入實現(xiàn)以鼠標為中心的縮放和畫布拖拽平移。第五步連線創(chuàng)建在兩個端口之間創(chuàng)建貝塞爾曲線。按下鼠標出線移動鼠標彎曲釋放鼠標完成連接。第六步撤銷重做接入快照機制。每次操作完成后壓棧撤銷時恢復(fù)上一狀態(tài)。第七步性能優(yōu)化加入網(wǎng)格索引、視口剔除、渲染節(jié)流。每一步之間我都跑了固定測試用例建 20 個節(jié)點連 30 條邊然后移動、縮放、撤銷、重做確保沒有回歸。整個開發(fā)周期大概用了三周半每天投入兩到三小時。時間的大頭花在連線的交互適配和框選的邊界問題上這兩個點最容易出細節(jié) bug。4.3 連線交互的完整實現(xiàn)連線是整個編輯器中交互邏輯最復(fù)雜的一塊我來重點展示它的實現(xiàn)路徑。連線創(chuàng)建屬于一種特殊模式用戶從源端口點擊按下此時畫布進入connecting模式鼠標移動時需要實時繪制一條從源端口到鼠標位置的“預(yù)覽連線”釋放鼠標時程序判斷目標位置是否為合法的目標端口合法則正式創(chuàng)建邊不合法則丟棄。預(yù)覽連線的形狀我用的是三階貝塞爾曲線。為什么用貝塞爾而不是直線或者折線因為貝塞爾曲線能以一條平滑曲線優(yōu)雅地連接兩個端口且可以根據(jù)兩個端口的朝向自動調(diào)整控制點不需要我在數(shù)據(jù)模型里存儲路徑信息。曲線的控制點確定規(guī)則是源端口朝向是左側(cè)控制點就向左邊延伸目標端口朝向是右側(cè)控制點就向右邊延伸。延伸距離取兩端口之間距離的一半這樣曲線彎曲幅度適中不會過彎也不會太直。function buildEdgePath(source: Point, target: Point, sourceDirection: Direction, targetDirection: Direction): Path2D { const dist Math.hypot(target.x - source.x, target.y - source.y); const offset dist * 0.5; const c1 offsetByDirection(source, sourceDirection, offset); const c2 offsetByDirection(target, targetDirection, offset); const path new Path2D(); path.moveTo(source.x, source.y); path.bezierCurveTo(c1.x, c1.y, c2.x, c2.y, target.x, target.y); return path; }目標端口的檢測也需要注意釋放鼠標時取鼠標所在坐標調(diào)用空間索引找到覆蓋該坐標的節(jié)點再判斷該節(jié)點上是否有端口在這個鼠標位置附近。如果命中則創(chuàng)建正式邊如果沒有命中直接把預(yù)覽連線清掉。創(chuàng)建邊之前還多一步合法性校驗一條邊不能連接同一個端口兩次也不允許從輸出端口連接到另一輸出端口具體取決于端口類型定義。這些規(guī)則放在數(shù)據(jù)層渲染層不做判斷這樣可以保證無論如何操作底層數(shù)據(jù)不會進入非法狀態(tài)。4.4 自動布局與對齊輔助用戶手動拖完一堆節(jié)點后圖必然歪歪扭扭。所以我在工具欄里加了兩個自動整理功能層級布局和垂直/水平對齊。層級布局適用于流程類圖把節(jié)點按照邊的方向分層同一層的節(jié)點排列成一列或一行層與層之間的距離相等。實現(xiàn)分三步拓撲排序確定每個節(jié)點的層級。同一層的節(jié)點按原始橫向順序排列間距均勻。邊的交叉最小化我用的是一個簡化的貪心算法逐層調(diào)整節(jié)點的順序讓相鄰層的邊交叉數(shù)量盡量小。垂直對齊和水平對齊的邏輯更簡單選中多個節(jié)點取一個基準坐標比如最左側(cè)節(jié)點的 x 或所有選中節(jié)點的均值把其他節(jié)點的對應(yīng)坐標改為基準值即可。對齊操作不是一個“永久狀態(tài)”用戶隨時可以再做手動調(diào)整所以它仍然落成數(shù)據(jù)層的坐標修改配合撤銷重做棧一起使用沒有引入額外復(fù)雜度。4.5 性能優(yōu)化實戰(zhàn)性能問題在節(jié)點數(shù)超過 300 之后開始顯現(xiàn)。第一件導(dǎo)致卡頓的事是每次重繪都清空整個畫布并重畫全部節(jié)點和邊。優(yōu)化手段是視口剔除只繪制當前視口可見范圍內(nèi)的元素function isInViewport(node: DiagramNode, viewport: Viewport): boolean { return ( node.x node.width viewport.left node.x viewport.right node.y node.height viewport.top node.y viewport.bottom ); }視口的邊界值直接由視口中心坐標和縮放后的窗口尺寸計算得出。由于世界坐標和視口邊界都經(jīng)過縮放換算這個判斷非常便宜。第二件導(dǎo)致卡頓的事是鼠標移動過程中觸發(fā)密集重繪。我引入了requestAnimationFrame節(jié)流移動事件只更新狀態(tài)標記不直接重繪動畫幀到來時檢查標記若有變化才重繪。這樣把重繪頻率從 mousemove 的每次觸發(fā)可以高達幾百次/秒降到了屏幕刷新率60次/秒體驗反而更平滑。第三件是字體渲染消耗。Canvas 每幀繪制大量文本字體解析很貴。優(yōu)化方案是把文本渲染單獨抽出來啟用ctx.font的緩存只有在字體字符串變化時才更新。實際測試中這個優(yōu)化帶來了 20% 左右的渲染耗時下降。5. 常見問題與排查技巧實錄5.1 高頻問題速查表我把開發(fā)過程中遇到的高頻問題整理成一張速查表每一個都附了對應(yīng)的排查思路?，F(xiàn)象可能原因排查/解決方式拖拽節(jié)點時圖形跳動事件綁定時誤用了局部坐標而非全局坐標確認鼠標事件計算的坐標已通過getBoundingClientRect去除畫布偏移滾輪縮放后視圖抖動縮放倍數(shù)是浮點累積導(dǎo)致精度漂移縮放后對 zoom 值做四舍五入保留兩位小數(shù)連線總是對不準目標端口端口坐標計算沒有考慮節(jié)點拖拽后的位移確保端口坐標在每次渲染前按節(jié)點當前世界坐標重新計算撤銷一步后整個圖回到幾秒前快照覆蓋了整個畫布拖拽中間態(tài)也被記錄連續(xù)操作只記錄起始和結(jié)束快照中間態(tài)丟棄框選時選中了看不見的節(jié)點屏幕坐標和世界坐標混用框選矩形按視口變換反算為世界坐標再進行相交判斷Canvas 文字發(fā)虛或模糊高 DPI 屏幕下沒有做像素比適配畫布實際尺寸乘以window.devicePixelRatio再設(shè)置 Canvas 物理像素5.2 一個典型的數(shù)據(jù)恢復(fù) bug 復(fù)盤我想單獨講講之前遇到的一個 bug它花了最長的時間?，F(xiàn)象是用戶打開一個保存過的圖形文件所有節(jié)點都在但節(jié)點之間原本存在的邊全部消失了或者邊的兩端都連到了奇怪的端口位置。初步排查時我懷疑是渲染層沒畫出來但控制臺輸出邊的數(shù)據(jù)是存在的。繼續(xù)追查發(fā)現(xiàn)邊的數(shù)據(jù)里記錄的sourcePortId和節(jié)點上的ports數(shù)組對不上——原來的端口 ID 在節(jié)點移動時被重置了但邊的數(shù)據(jù)沒有同步更新。根因是節(jié)點有一個“重置端口”的操作邏輯會為端口生成新的 UUID但此時關(guān)聯(lián)邊仍然握著舊端口的 ID。因為沒有做級聯(lián)更新舊端口 ID 查無此人渲染層自然畫不出連線。修復(fù)辦法是在重置端口的邏輯里增加一步先遍歷所有關(guān)聯(lián)該節(jié)點的邊把邊的端口 ID 更新為新端口 ID然后再執(zhí)行重置操作。這個案例給到一個通用教訓圖數(shù)據(jù)模型里凡是要改節(jié)點內(nèi)部標識符ID的操作必須先檢查關(guān)聯(lián)邊的引用關(guān)系。這類引用一致性問題是圖編輯器的地雷往往不會當場爆而是在用戶重新加載時爆。5.3 排除性能瓶頸的順序策略當畫布開始卡頓我的排查順序是先看是否在拖拽/縮放的動畫幀里做了全量重繪。這是最常見的性能殺手占比超過一半。再看命中和渲染是否做了無謂的遍歷。例如每次鼠標移動觸發(fā)全量遍歷而不是網(wǎng)格索引。然后檢查是否有內(nèi)存泄漏導(dǎo)致的 GC 壓力典型情況是事件監(jiān)聽器沒有解除。最后才看圖形本身的繪制開銷比如陰影、漸變這類視覺效果本身會拖慢渲染。前三個問題都是代碼結(jié)構(gòu)問題修復(fù)成本低效果立竿見影。第四個通常是為了視覺效果做出的主動取舍需要靠視覺降級方案比如只在選中的節(jié)點上繪制陰影而不是所有節(jié)點來平衡。6. 關(guān)于擴展方向的一點體會圖表設(shè)計做到這里基礎(chǔ)能力已經(jīng)完整了但我梳理下來發(fā)現(xiàn)還可以往幾個方向走。一個是把導(dǎo)出能力增強。目前只能導(dǎo)出 JSON 和圖片快照后續(xù)可以支持導(dǎo)出為 SVG 源文件、Markdown 內(nèi)嵌圖或者直接生成 PDF。導(dǎo)出 SVG 的時候需要注意Canvas 里的貝塞爾曲線要原樣轉(zhuǎn)成 SVG 的 path 元素文本節(jié)點需要轉(zhuǎn)成 text 元素并且保留字體的 family 和 size 屬性。另一個方向是多頁面支持。當前的圖是一張單畫布如果業(yè)務(wù)上需要同時管理多張圖需要加一層項目對象把圖組織成樹形結(jié)構(gòu)支持跨圖復(fù)制節(jié)點和引用關(guān)系。再一個是協(xié)作能力。多人同時編輯同一張圖是個很誘人的擴展。但要注意實時協(xié)作對數(shù)據(jù)模型的耦合度要求非常高節(jié)點 ID 必須全局唯一、邊引用必須跨端保持一致、操作記錄需要支持 CRDT 或版本向量。我的體會是如果業(yè)務(wù)沒有剛需盡量晚點碰這一塊先保證單機體驗足夠扎實。從實際交付的角度講單機圖表編輯器做好已經(jīng)能覆蓋大多數(shù)真實場景。做復(fù)雜系統(tǒng)的圖設(shè)計工具第一步永遠是數(shù)據(jù)模型穩(wěn)不穩(wěn)而不是渲染漂不漂亮。我寫的所有代碼里給之后項目復(fù)用最多的也是那套數(shù)據(jù)模型和狀態(tài)管理思路而不是任何一處渲染效果。最后分享一個實際調(diào)試中的小技巧節(jié)點多的時候不要靠人眼看圖找 bug我會在畫布里臨時按 F2 提前一層紋理把節(jié)點 ID 直接打印在每個節(jié)點的左下角。雖然它不會出現(xiàn)在正式交付版本里但排查邊連錯、端口錯位、序列化還原不一致這類問題效率能提升好幾倍。