太厚？3步手寫實(shí)現(xiàn)核心API，吃透繪圖底層)
Canvas中文官網(wǎng)太厚？3步手寫實(shí)現(xiàn)核心API，吃透繪圖底層
MDN Web Docs 里的 Canvas 章節(jié)動(dòng)輒幾十頁，全是 API 羅列，新手讀完后依然不知道 fillRect 背后發(fā)生了什么。官方文檔太長(zhǎng)抓不住重點(diǎn)，導(dǎo)致很多人只會(huì)在代碼里復(fù)制粘貼，一旦遇到性能瓶頸或復(fù)雜圖形渲染，就徹底懵了。
與其死磕文檔，不如手寫實(shí)現(xiàn)幾個(gè)核心方法。通過逆向工程的方式，用原生代碼模擬 Canvas 的繪制邏輯，你才能真正理解“狀態(tài)棧”、“坐標(biāo)變換”和“路徑緩存”這三個(gè)底層機(jī)制。今天這篇干貨，不講虛的，直接拆解 Canvas 的核心原理，配合代碼實(shí)戰(zhàn)，讓你從“會(huì)用”進(jìn)階到“懂原理”。
1. 一句話原理：Canvas 其實(shí)是一個(gè)二維像素網(wǎng)格
很多人誤以為 Canvas 是畫布，其實(shí)它更像一個(gè)巨大的二維數(shù)組。
在瀏覽器的內(nèi)存中，Canvas 元素背后維護(hù)著一張位圖（Bitmap）。當(dāng)你調(diào)用 ctx.fillRect(0, 0, 100, 100) 時(shí)，瀏覽器并沒有真的拿一支筆去畫，而是直接修改了內(nèi)存中對(duì)應(yīng)區(qū)域的像素值。
這就是為什么 Canvas 的性能與“重繪面積”強(qiáng)相關(guān)，而與 DOM 節(jié)點(diǎn)數(shù)量無關(guān)。理解這一點(diǎn)，你就明白了為什么在 Canvas 中做大量的小元素繪制，往往比操作大量 DOM 節(jié)點(diǎn)要快得多——因?yàn)榍罢咧皇莾?nèi)存位圖的像素刷新，后者涉及復(fù)雜的布局（Layout）和繪制（Paint）計(jì)算。
核心概念拆解：Context（上下文）：它是你與像素網(wǎng)格交互的接口，持有了當(dāng)前的繪圖狀態(tài)（顏色、透明度、變換矩陣等）。
Path（路徑）：它不是像素，而是一組指令集（移動(dòng)、直線、曲線）。路徑本身不占內(nèi)存像素，只有當(dāng)調(diào)用 stroke() 或 fill() 時(shí)，才會(huì)根據(jù)路徑指令去計(jì)算像素覆蓋范圍。
State Stack（狀態(tài)棧）：Canvas 的所有樣式設(shè)置（如 fillStyle、transform）都是全局共享的。為了防止?fàn)顟B(tài)污染，引入了 save() 和 restore() 機(jī)制。2. 類比解釋：狀態(tài)機(jī)與“橡皮章”
為了理解 Canvas 的“狀態(tài)”機(jī)制，我們可以把它想象成一個(gè)帶有記憶功能的橡皮章。
假設(shè)你有一枚紅色的圓形橡皮章（fillStyle = 'red'），你想在紙上蓋三個(gè)章。默認(rèn)狀態(tài)：章是紅色的，位置在原點(diǎn)。
操作 A：你把章向右移動(dòng) 100 像素，蓋了一個(gè)章。此時(shí)章的位置變了，但顏色沒變。
操作 B：你想把章變成藍(lán)色，再蓋一個(gè)。如果你直接改顏色，原來的紅色狀態(tài)就丟了。
解決思路：如果你能有一個(gè)“存檔點(diǎn)”，在改顏色前存檔，蓋完藍(lán)色的章后讀檔，章就變回紅色了。Canvas 的 save() 和 restore() 就是這個(gè)“存檔”和“讀檔”。save()：把當(dāng)前的所有狀態(tài)（顏色、線寬、變換矩陣、裁剪區(qū)域）壓入棧頂。
restore()：從棧頂彈出一個(gè)狀態(tài)，覆蓋當(dāng)前所有設(shè)置。為什么需要這個(gè)機(jī)制？
在繪制復(fù)雜圖形（如儀表盤、雷達(dá)圖）時(shí)，每個(gè)扇形可能只需要旋轉(zhuǎn)特定的角度。如果每次旋轉(zhuǎn)后不重置變換矩陣，下一個(gè)扇形就會(huì)在錯(cuò)誤的角度上繼續(xù)旋轉(zhuǎn)，導(dǎo)致圖形錯(cuò)亂。使用 save() 保存初始狀態(tài)，繪制完一個(gè)扇形后 restore()，就能保證每個(gè)扇形都從正確的原點(diǎn)開始旋轉(zhuǎn)。
3. 源碼/偽代碼片段：手寫簡(jiǎn)易 Canvas 狀態(tài)管理
為了驗(yàn)證上述原理，我們用 JavaScript 手寫實(shí)現(xiàn)一個(gè)極簡(jiǎn)版的 Canvas Context 管理器。這里我們不直接操作像素（那涉及 WebGL 或 C++ 底層），而是模擬瀏覽器的狀態(tài)管理邏輯，重點(diǎn)展示“狀態(tài)?！焙汀奥窂街噶睢钡慕怦睢?class SimpleCanvasContext {constructor() {this.stateStack = [];this.currentPath = [];this.currentStyle = {fill: '#000',stroke: '#fff',lineWidth: 1,transform: [1, 0, 0, 1, 0, 0] // a, b, c, d, e, f 仿射變換矩陣};}// 模擬 save()：壓棧save() {// 深拷貝當(dāng)前狀態(tài)，防止引用問題const currentState = {...this.currentStyle,path: [...this.currentPath] };this.stateStack.push(currentState);console.log(`[Save] State pushed. Stack size: ${this.stateStack.length}`);}// 模擬 restore()：出棧restore() {if (this.stateStack.length === 0) {console.warn('Stack is empty, restore ignored.');return;}const prevState = this.stateStack.pop();this.currentStyle = prevState.style;this.currentPath = prevState.path;console.log(`[Restore] State popped. Stack size: ${this.stateStack.length}`);}// 模擬 moveTo: 記錄路徑指令，不立即渲染moveTo(x, y) {this.currentPath.push({ type: 'move', x, y });}// 模擬 lineTo: 記錄路徑指令lineTo(x, y) {this.currentPath.push({ type: 'line', x, y });}// 模擬 fill: 觸發(fā)渲染邏輯fill() {if (this.currentPath.length === 0) return;console.log(`[Fill] Rendering path with style: ${this.currentStyle.fill}`);console.log(`[Fill] Path commands:`, this.currentPath);// 在實(shí)際瀏覽器中，這里會(huì)調(diào)用 C++ 層面的 Rasterizer 將路徑光柵化到位圖// 這里我們模擬“清除路徑”，因?yàn)闃?biāo)準(zhǔn) Canvas 在 fill 后不會(huì)自動(dòng)清除路徑，// 但為了演示狀態(tài)獨(dú)立性，我們假設(shè)每次 fill 后路徑結(jié)束this.currentPath = []; }// 模擬 rotate: 修改變換矩陣rotate(angle) {const cos = Math.cos(angle);const sin = Math.sin(angle);// 簡(jiǎn)化：直接覆蓋變換矩陣的 a, b, c, d 部分this.currentStyle.transform = [cos, sin, -sin, cos, 0, 0];console.log(`[Rotate] Angle: ${angle}, New Transform: ${this.currentStyle.transform}`);}
}// 實(shí)戰(zhàn)演示
const ctx = new SimpleCanvasContext();// 1. 繪制第一個(gè)矩形（默認(rèn)狀態(tài)）
ctx.fillStyle = 'red';
ctx.save();
ctx.rotate(Math.PI / 2); // 旋轉(zhuǎn)90度
ctx.moveTo(0, 0);
ctx.lineTo(50, 0);
ctx.fill();// 2. 繪制第二個(gè)矩形（恢復(fù)狀態(tài)）
ctx.restore();
ctx.fillStyle = 'blue';
ctx.moveTo(0, 0);
ctx.lineTo(50, 0);
ctx.fill();代碼解讀與底層映射：stateStack 數(shù)組：這就是瀏覽器內(nèi)部的“狀態(tài)棧”。每次 save()，都將當(dāng)前 currentStyle 和 currentPath 的快照推入數(shù)組。
路徑指令集 currentPath：注意 moveTo 和 lineTo 只是 push 了一個(gè)對(duì)象，并沒有任何渲染動(dòng)作。這印證了路徑是懶執(zhí)行的。只有調(diào)用 fill() 或 stroke() 時(shí)，瀏覽器才會(huì)遍歷這個(gè)指令集，結(jié)合當(dāng)前的 transform 矩陣，計(jì)算出最終的像素坐標(biāo)。
變換矩陣 transform：在 rotate 方法中，我們修改了矩陣值。在真實(shí)瀏覽器中，這個(gè)矩陣會(huì)在每次 fill 時(shí)被應(yīng)用到路徑的每個(gè)控制點(diǎn)上。如果我們?cè)?rotate 后不 restore，下一次繪制就會(huì)基于旋轉(zhuǎn)后的坐標(biāo)系，導(dǎo)致圖形錯(cuò)位。4. 流程描述：從 JS 調(diào)用到底層渲染
當(dāng)我們執(zhí)行 ctx.fillRect(0, 0, 100, 100) 時(shí)，瀏覽器內(nèi)部經(jīng)歷了以下四個(gè)階段：JS 層（JavaScript Engine）：
V8 引擎接收調(diào)用，校驗(yàn)參數(shù)類型。如果參數(shù)非法（如 NaN），拋出異常。如果合法，將調(diào)用封裝成一個(gè)內(nèi)部函數(shù)調(diào)用。Blink 層（Chromium 渲染引擎）：
這是 Canvas 邏輯處理的核心。狀態(tài)檢查：檢查當(dāng)前 Context 是否有效（Canvas 是否被移除、Context 是否丟失）。
路徑構(gòu)建：如果是 fillRect，內(nèi)部會(huì)隱式地構(gòu)建一個(gè)矩形路徑（MoveTo - LineTo x4 - ClosePath）。
變換應(yīng)用：將路徑上的點(diǎn)與當(dāng)前的 transform 矩陣相乘，得到屏幕坐標(biāo)系下的點(diǎn)。
光柵化準(zhǔn)備：確定該路徑覆蓋的像素范圍（Bounding Box）。Skia 層（2D 圖形庫）：
Chromium 使用 Skia 作為 2D 繪圖后端。掃描線算法（Scanline）：對(duì)于填充操作，Skia 使用掃描線算法，逐行掃描路徑內(nèi)部，標(biāo)記哪些像素需要被填充。
混合模式（Blending）：根據(jù) globalCompositeOperation（默認(rèn)是 source-over），計(jì)算新像素顏色與舊像素顏色的混合公式。公式通常為：\(C_{result} = C_{source} \times A_{source} + C_{destination} \times (1 - A_{source})\)。
GPU 加速判斷：如果瀏覽器啟用了硬件加速，Skia 會(huì)將繪制指令轉(zhuǎn)換為 OpenGL/Vulkan 指令，發(fā)送給 GPU。此時(shí)，Canvas 的內(nèi)容會(huì)被繪制到一個(gè) Texture（紋理）上。合成層（Compositing）：
最終的紋理（Texture）會(huì)被上傳到 GPU 顯存，與其他圖層（如 DOM 元素、視頻）一起進(jìn)行合成，最終輸出到屏幕。關(guān)鍵瓶頸分析：CPU 瓶頸：如果未開啟硬件加速，或繪制操作過于復(fù)雜（如大量抗鋸齒曲線），Skia 的掃描線算法會(huì)占用大量 CPU 時(shí)間。
內(nèi)存帶寬瓶頸：每次 fill 或 stroke 都會(huì)讀寫幀緩沖（Frame Buffer）。如果繪制區(qū)域重疊且頻繁刷新，內(nèi)存帶寬將成為瓶頸。這就是為什么建議將靜態(tài)背景與動(dòng)態(tài)前景分層 Canvas，避免每次動(dòng)態(tài)更新都重繪整個(gè)背景。5. 實(shí)戰(zhàn)驗(yàn)證：性能優(yōu)化的底層依據(jù)
理解了上述流程，我們就能解釋為什么某些寫法快，某些寫法慢，并進(jìn)行針對(duì)性的優(yōu)化。
場(chǎng)景：繪制 1000 個(gè)隨機(jī)分布的小圓點(diǎn)。
寫法 A（錯(cuò)誤示范）：
for (let i = 0; i 1000; i++) {ctx.beginPath();ctx.arc(x[i], y[i], 2, 0, Math.PI * 2);ctx.fill(); // 每次循環(huán)都觸發(fā)一次光柵化和 GPU 上傳
}分析：
每次 fill() 都會(huì)觸發(fā)一次 Skia 的路徑光柵化和一次 GPU 指令提交。1000 次提交意味著 1000 次驅(qū)動(dòng)調(diào)用和 1000 次混合計(jì)算。這在低端設(shè)備上會(huì)掉幀嚴(yán)重。
寫法 B（優(yōu)化方案）：
ctx.beginPath();
for (let i = 0; i 1000; i++) {ctx.moveTo(x[i], y[i]);ctx.arc(x[i], y[i], 2, 0, Math.PI * 2);
}
ctx.fill(); // 一次性提交所有路徑分析：
雖然路徑數(shù)量多了，但 fill() 只調(diào)用了一次。Skia 可以批量處理這 1000 個(gè)圓的路徑光柵化，GPU 也可以在一個(gè) Draw Call 中處理所有圖元。通常性能提升 3-5 倍。
寫法 C（極致優(yōu)化 - 離屏 Canvas）：
如果這 1000 個(gè)點(diǎn)是靜態(tài)的（位置不變，顏色不變）：
const offscreen = document.createElement('canvas');
offscreen.width = canvas.width;
offscreen.height = canvas.height;
const offCtx = offscreen.getContext('2d');// 在離屏 Canvas 上繪制 1000 個(gè)點(diǎn)（一次性）
// ... 繪制邏輯 ...// 在主循環(huán)中，只需 blit（位塊傳輸）
function render() {ctx.clearRect(0, 0, canvas.width, canvas.height);ctx.drawImage(offscreen, 0, 0); // GPU 直接復(fù)制紋理，極快// 繪制動(dòng)態(tài)元素
}分析：
drawImage 是一個(gè) GPU 紋理復(fù)制操作，成本極低。將靜態(tài)內(nèi)容預(yù)渲染到離屏 Canvas，避免了每幀重復(fù)執(zhí)行復(fù)雜的路徑計(jì)算和光柵化。這是游戲開發(fā)和高頻圖表渲染的標(biāo)準(zhǔn)做法。
避坑指南：避免頻繁改變 fillStyle：如果 1000 個(gè)點(diǎn)顏色不同，寫法 B 失效，因?yàn)?fill() 只能使用單一顏色。此時(shí)應(yīng)使用 Path2D 對(duì)象配合不同的顏色分組，或者使用 WebGL 接管渲染。
注意 imageSmoothingEnabled：默認(rèn)開啟平滑（抗鋸齒），在繪制大量小像素點(diǎn)時(shí)會(huì)增加 CPU 負(fù)擔(dān)。如果不需要平滑，設(shè)為 false 可提升性能。
DPR 適配：在高分屏上，Canvas 的物理像素是 CSS 像素的 2 倍或 3 倍。如果未手動(dòng)設(shè)置 canvas.width = cssWidth * dpr 并縮放 Context，畫面會(huì)模糊。這是因?yàn)闉g覽器將 1 個(gè)邏輯像素映射到了多個(gè)物理像素，導(dǎo)致采樣率不足。6. 總結(jié)與思考
通過手寫實(shí)現(xiàn)狀態(tài)管理和路徑邏輯，我們看清了 Canvas 的本質(zhì)：它不是一個(gè)畫板，而是一個(gè)基于狀態(tài)機(jī)的像素緩沖管理器。MDN Web Docs 提供了 API 的規(guī)范定義，但往往省略了這些底層狀態(tài)轉(zhuǎn)換的細(xì)節(jié)。
理解“路徑是指令集，不是像素”，你就明白了為什么 beginPath 很重要。
理解“狀態(tài)棧是快照”，你就明白了為什么 save/restore 是復(fù)雜圖形繪制的基石。
理解“光柵化發(fā)生在 fill/stroke”，你就明白了為什么批量提交比單次提交快。對(duì)于培訓(xùn)機(jī)構(gòu)學(xué)員或初級(jí)開發(fā)者來說，不要滿足于“能跑就行”。當(dāng)你遇到 Canvas 卡頓、圖形錯(cuò)位、模糊等問題時(shí)，不要只去搜 Stack Overflow 的現(xiàn)成代碼，而是回到這三個(gè)底層原理去排查。
最后拋出一個(gè)問題供評(píng)論區(qū)討論：
在實(shí)際項(xiàng)目中，你更傾向于使用原生 Canvas 2D API 進(jìn)行復(fù)雜圖形繪制，還是直接上 WebGL/Three.js 來處理？在什么閾值下，你會(huì)決定從 2D 切換到 3D 或 WebGL 方案？歡迎在評(píng)論區(qū)分享你的經(jīng)驗(yàn)。 Canvas中文官網(wǎng)太厚？3步手寫實(shí)現(xiàn)核心API，吃透繪圖底層
Canvas中文官網(wǎng)太厚？3步手寫實(shí)現(xiàn)核心API，吃透繪圖底層
MDN Web Docs 里的 Canvas 章節(jié)動(dòng)輒幾十頁，全是 API 羅列，新手讀完后依然不知道 fillRect 背后發(fā)生了什么。官方文檔太長(zhǎng)抓不住重點(diǎn)，導(dǎo)致很多人只會(huì)在代碼里復(fù)制粘貼，一旦遇到性能瓶頸或復(fù)雜圖形渲染，就徹底懵了。
與其死磕文檔，不如手寫實(shí)現(xiàn)幾個(gè)核心方法。通過逆向工程的方式，用原生代碼模擬 Canvas 的繪制邏輯，你才能真正理解“狀態(tài)棧”、“坐標(biāo)變換”和“路徑緩存”這三個(gè)底層機(jī)制。今天這篇干貨，不講虛的，直接拆解 Canvas 的核心原理，配合代碼實(shí)戰(zhàn)，讓你從“會(huì)用”進(jìn)階到“懂原理”。
1. 一句話原理：Canvas 其實(shí)是一個(gè)二維像素網(wǎng)格
很多人誤以為 Canvas 是畫布，其實(shí)它更像一個(gè)巨大的二維數(shù)組。
在瀏覽器的內(nèi)存中，Canvas 元素背后維護(hù)著一張位圖（Bitmap）。當(dāng)你調(diào)用 ctx.fillRect(0, 0, 100, 100) 時(shí)，瀏覽器并沒有真的拿一支筆去畫，而是直接修改了內(nèi)存中對(duì)應(yīng)區(qū)域的像素值。
這就是為什么 Canvas 的性能與“重繪面積”強(qiáng)相關(guān)，而與 DOM 節(jié)點(diǎn)數(shù)量無關(guān)。理解這一點(diǎn)，你就明白了為什么在 Canvas 中做大量的小元素繪制，往往比操作大量 DOM 節(jié)點(diǎn)要快得多——因?yàn)榍罢咧皇莾?nèi)存位圖的像素刷新，后者涉及復(fù)雜的布局（Layout）和繪制（Paint）計(jì)算。
核心概念拆解：Context（上下文）：它是你與像素網(wǎng)格交互的接口，持有了當(dāng)前的繪圖狀態(tài)（顏色、透明度、變換矩陣等）。
Path（路徑）：它不是像素，而是一組指令集（移動(dòng)、直線、曲線）。路徑本身不占內(nèi)存像素，只有當(dāng)調(diào)用 stroke() 或 fill() 時(shí)，才會(huì)根據(jù)路徑指令去計(jì)算像素覆蓋范圍。
State Stack（狀態(tài)棧）：Canvas 的所有樣式設(shè)置（如 fillStyle、transform）都是全局共享的。為了防止?fàn)顟B(tài)污染，引入了 save() 和 restore() 機(jī)制。2. 類比解釋：狀態(tài)機(jī)與“橡皮章”
為了理解 Canvas 的“狀態(tài)”機(jī)制，我們可以把它想象成一個(gè)帶有記憶功能的橡皮章。
假設(shè)你有一枚紅色的圓形橡皮章（fillStyle = 'red'），你想在紙上蓋三個(gè)章。默認(rèn)狀態(tài)：章是紅色的，位置在原點(diǎn)。
操作 A：你把章向右移動(dòng) 100 像素，蓋了一個(gè)章。此時(shí)章的位置變了，但顏色沒變。
操作 B：你想把章變成藍(lán)色，再蓋一個(gè)。如果你直接改顏色，原來的紅色狀態(tài)就丟了。
解決思路：如果你能有一個(gè)“存檔點(diǎn)”，在改顏色前存檔，蓋完藍(lán)色的章后讀檔，章就變回紅色了。Canvas 的 save() 和 restore() 就是這個(gè)“存檔”和“讀檔”。save()：把當(dāng)前的所有狀態(tài)（顏色、線寬、變換矩陣、裁剪區(qū)域）壓入棧頂。
restore()：從棧頂彈出一個(gè)狀態(tài)，覆蓋當(dāng)前所有設(shè)置。為什么需要這個(gè)機(jī)制？
在繪制復(fù)雜圖形（如儀表盤、雷達(dá)圖）時(shí)，每個(gè)扇形可能只需要旋轉(zhuǎn)特定的角度。如果每次旋轉(zhuǎn)后不重置變換矩陣，下一個(gè)扇形就會(huì)在錯(cuò)誤的角度上繼續(xù)旋轉(zhuǎn)，導(dǎo)致圖形錯(cuò)亂。使用 save() 保存初始狀態(tài)，繪制完一個(gè)扇形后 restore()，就能保證每個(gè)扇形都從正確的原點(diǎn)開始旋轉(zhuǎn)。
3. 源碼/偽代碼片段：手寫簡(jiǎn)易 Canvas 狀態(tài)管理
為了驗(yàn)證上述原理，我們用 JavaScript 手寫實(shí)現(xiàn)一個(gè)極簡(jiǎn)版的 Canvas Context 管理器。這里我們不直接操作像素（那涉及 WebGL 或 C++ 底層），而是模擬瀏覽器的狀態(tài)管理邏輯，重點(diǎn)展示“狀態(tài)?！焙汀奥窂街噶睢钡慕怦睢?class SimpleCanvasContext {constructor() {this.stateStack = [];this.currentPath = [];this.currentStyle = {fill: '#000',stroke: '#fff',lineWidth: 1,transform: [1, 0, 0, 1, 0, 0] // a, b, c, d, e, f 仿射變換矩陣};}// 模擬 save()：壓棧save() {// 深拷貝當(dāng)前狀態(tài)，防止引用問題const currentState = {...this.currentStyle,path: [...this.currentPath] };this.stateStack.push(currentState);console.log(`[Save] State pushed. Stack size: ${this.stateStack.length}`);}// 模擬 restore()：出棧restore() {if (this.stateStack.length === 0) {console.warn('Stack is empty, restore ignored.');return;}const prevState = this.stateStack.pop();this.currentStyle = prevState.style;this.currentPath = prevState.path;console.log(`[Restore] State popped. Stack size: ${this.stateStack.length}`);}// 模擬 moveTo: 記錄路徑指令，不立即渲染moveTo(x, y) {this.currentPath.push({ type: 'move', x, y });}// 模擬 lineTo: 記錄路徑指令lineTo(x, y) {this.currentPath.push({ type: 'line', x, y });}// 模擬 fill: 觸發(fā)渲染邏輯fill() {if (this.currentPath.length === 0) return;console.log(`[Fill] Rendering path with style: ${this.currentStyle.fill}`);console.log(`[Fill] Path commands:`, this.currentPath);// 在實(shí)際瀏覽器中，這里會(huì)調(diào)用 C++ 層面的 Rasterizer 將路徑光柵化到位圖// 這里我們模擬“清除路徑”，因?yàn)闃?biāo)準(zhǔn) Canvas 在 fill 后不會(huì)自動(dòng)清除路徑，// 但為了演示狀態(tài)獨(dú)立性，我們假設(shè)每次 fill 后路徑結(jié)束this.currentPath = []; }// 模擬 rotate: 修改變換矩陣rotate(angle) {const cos = Math.cos(angle);const sin = Math.sin(angle);// 簡(jiǎn)化：直接覆蓋變換矩陣的 a, b, c, d 部分this.currentStyle.transform = [cos, sin, -sin, cos, 0, 0];console.log(`[Rotate] Angle: ${angle}, New Transform: ${this.currentStyle.transform}`);}
}// 實(shí)戰(zhàn)演示
const ctx = new SimpleCanvasContext();// 1. 繪制第一個(gè)矩形（默認(rèn)狀態(tài)）
ctx.fillStyle = 'red';
ctx.save();
ctx.rotate(Math.PI / 2); // 旋轉(zhuǎn)90度
ctx.moveTo(0, 0);
ctx.lineTo(50, 0);
ctx.fill();// 2. 繪制第二個(gè)矩形（恢復(fù)狀態(tài)）
ctx.restore();
ctx.fillStyle = 'blue';
ctx.moveTo(0, 0);
ctx.lineTo(50, 0);
ctx.fill();代碼解讀與底層映射：stateStack 數(shù)組：這就是瀏覽器內(nèi)部的“狀態(tài)棧”。每次 save()，都將當(dāng)前 currentStyle 和 currentPath 的快照推入數(shù)組。
路徑指令集 currentPath：注意 moveTo 和 lineTo 只是 push 了一個(gè)對(duì)象，并沒有任何渲染動(dòng)作。這印證了路徑是懶執(zhí)行的。只有調(diào)用 fill() 或 stroke() 時(shí)，瀏覽器才會(huì)遍歷這個(gè)指令集，結(jié)合當(dāng)前的 transform 矩陣，計(jì)算出最終的像素坐標(biāo)。
變換矩陣 transform：在 rotate 方法中，我們修改了矩陣值。在真實(shí)瀏覽器中，這個(gè)矩陣會(huì)在每次 fill 時(shí)被應(yīng)用到路徑的每個(gè)控制點(diǎn)上。如果我們?cè)?rotate 后不 restore，下一次繪制就會(huì)基于旋轉(zhuǎn)后的坐標(biāo)系，導(dǎo)致圖形錯(cuò)位。4. 流程描述：從 JS 調(diào)用到底層渲染
當(dāng)我們執(zhí)行 ctx.fillRect(0, 0, 100, 100) 時(shí)，瀏覽器內(nèi)部經(jīng)歷了以下四個(gè)階段：JS 層（JavaScript Engine）：
V8 引擎接收調(diào)用，校驗(yàn)參數(shù)類型。如果參數(shù)非法（如 NaN），拋出異常。如果合法，將調(diào)用封裝成一個(gè)內(nèi)部函數(shù)調(diào)用。Blink 層（Chromium 渲染引擎）：
這是 Canvas 邏輯處理的核心。狀態(tài)檢查：檢查當(dāng)前 Context 是否有效（Canvas 是否被移除、Context 是否丟失）。
路徑構(gòu)建：如果是 fillRect，內(nèi)部會(huì)隱式地構(gòu)建一個(gè)矩形路徑（MoveTo - LineTo x4 - ClosePath）。
變換應(yīng)用：將路徑上的點(diǎn)與當(dāng)前的 transform 矩陣相乘，得到屏幕坐標(biāo)系下的點(diǎn)。
光柵化準(zhǔn)備：確定該路徑覆蓋的像素范圍（Bounding Box）。Skia 層（2D 圖形庫）：
Chromium 使用 Skia 作為 2D 繪圖后端。掃描線算法（Scanline）：對(duì)于填充操作，Skia 使用掃描線算法，逐行掃描路徑內(nèi)部，標(biāo)記哪些像素需要被填充。
混合模式（Blending）：根據(jù) globalCompositeOperation（默認(rèn)是 source-over），計(jì)算新像素顏色與舊像素顏色的混合公式。公式通常為：\(C_{result} = C_{source} \times A_{source} + C_{destination} \times (1 - A_{source})\)。
GPU 加速判斷：如果瀏覽器啟用了硬件加速，Skia 會(huì)將繪制指令轉(zhuǎn)換為 OpenGL/Vulkan 指令，發(fā)送給 GPU。此時(shí)，Canvas 的內(nèi)容會(huì)被繪制到一個(gè) Texture（紋理）上。合成層（Compositing）：
最終的紋理（Texture）會(huì)被上傳到 GPU 顯存，與其他圖層（如 DOM 元素、視頻）一起進(jìn)行合成，最終輸出到屏幕。關(guān)鍵瓶頸分析：CPU 瓶頸：如果未開啟硬件加速，或繪制操作過于復(fù)雜（如大量抗鋸齒曲線），Skia 的掃描線算法會(huì)占用大量 CPU 時(shí)間。
內(nèi)存帶寬瓶頸：每次 fill 或 stroke 都會(huì)讀寫幀緩沖（Frame Buffer）。如果繪制區(qū)域重疊且頻繁刷新，內(nèi)存帶寬將成為瓶頸。這就是為什么建議將靜態(tài)背景與動(dòng)態(tài)前景分層 Canvas，避免每次動(dòng)態(tài)更新都重繪整個(gè)背景。5. 實(shí)戰(zhàn)驗(yàn)證：性能優(yōu)化的底層依據(jù)
理解了上述流程，我們就能解釋為什么某些寫法快，某些寫法慢，并進(jìn)行針對(duì)性的優(yōu)化。
場(chǎng)景：繪制 1000 個(gè)隨機(jī)分布的小圓點(diǎn)。
寫法 A（錯(cuò)誤示范）：
for (let i = 0; i 1000; i++) {ctx.beginPath();ctx.arc(x[i], y[i], 2, 0, Math.PI * 2);ctx.fill(); // 每次循環(huán)都觸發(fā)一次光柵化和 GPU 上傳
}分析：
每次 fill() 都會(huì)觸發(fā)一次 Skia 的路徑光柵化和一次 GPU 指令提交。1000 次提交意味著 1000 次驅(qū)動(dòng)調(diào)用和 1000 次混合計(jì)算。這在低端設(shè)備上會(huì)掉幀嚴(yán)重。
寫法 B（優(yōu)化方案）：
ctx.beginPath();
for (let i = 0; i 1000; i++) {ctx.moveTo(x[i], y[i]);ctx.arc(x[i], y[i], 2, 0, Math.PI * 2);
}
ctx.fill(); // 一次性提交所有路徑分析：
雖然路徑數(shù)量多了，但 fill() 只調(diào)用了一次。Skia 可以批量處理這 1000 個(gè)圓的路徑光柵化，GPU 也可以在一個(gè) Draw Call 中處理所有圖元。通常性能提升 3-5 倍。
寫法 C（極致優(yōu)化 - 離屏 Canvas）：
如果這 1000 個(gè)點(diǎn)是靜態(tài)的（位置不變，顏色不變）：
const offscreen = document.createElement('canvas');
offscreen.width = canvas.width;
offscreen.height = canvas.height;
const offCtx = offscreen.getContext('2d');// 在離屏 Canvas 上繪制 1000 個(gè)點(diǎn)（一次性）
// ... 繪制邏輯 ...// 在主循環(huán)中，只需 blit（位塊傳輸）
function render() {ctx.clearRect(0, 0, canvas.width, canvas.height);ctx.drawImage(offscreen, 0, 0); // GPU 直接復(fù)制紋理，極快// 繪制動(dòng)態(tài)元素
}分析：
drawImage 是一個(gè) GPU 紋理復(fù)制操作，成本極低。將靜態(tài)內(nèi)容預(yù)渲染到離屏 Canvas，避免了每幀重復(fù)執(zhí)行復(fù)雜的路徑計(jì)算和光柵化。這是游戲開發(fā)和高頻圖表渲染的標(biāo)準(zhǔn)做法。
避坑指南：避免頻繁改變 fillStyle：如果 1000 個(gè)點(diǎn)顏色不同，寫法 B 失效，因?yàn)?fill() 只能使用單一顏色。此時(shí)應(yīng)使用 Path2D 對(duì)象配合不同的顏色分組，或者使用 WebGL 接管渲染。
注意 imageSmoothingEnabled：默認(rèn)開啟平滑（抗鋸齒），在繪制大量小像素點(diǎn)時(shí)會(huì)增加 CPU 負(fù)擔(dān)。如果不需要平滑，設(shè)為 false 可提升性能。
DPR 適配：在高分屏上，Canvas 的物理像素是 CSS 像素的 2 倍或 3 倍。如果未手動(dòng)設(shè)置 canvas.width = cssWidth * dpr 并縮放 Context，畫面會(huì)模糊。這是因?yàn)闉g覽器將 1 個(gè)邏輯像素映射到了多個(gè)物理像素，導(dǎo)致采樣率不足。6. 總結(jié)與思考
通過手寫實(shí)現(xiàn)狀態(tài)管理和路徑邏輯，我們看清了 Canvas 的本質(zhì)：它不是一個(gè)畫板，而是一個(gè)基于狀態(tài)機(jī)的像素緩沖管理器。MDN Web Docs 提供了 API 的規(guī)范定義，但往往省略了這些底層狀態(tài)轉(zhuǎn)換的細(xì)節(jié)。
理解“路徑是指令集，不是像素”，你就明白了為什么 beginPath 很重要。
理解“狀態(tài)棧是快照”，你就明白了為什么 save/restore 是復(fù)雜圖形繪制的基石。
理解“光柵化發(fā)生在 fill/stroke”，你就明白了為什么批量提交比單次提交快。對(duì)于培訓(xùn)機(jī)構(gòu)學(xué)員或初級(jí)開發(fā)者來說，不要滿足于“能跑就行”。當(dāng)你遇到 Canvas 卡頓、圖形錯(cuò)位、模糊等問題時(shí)，不要只去搜 Stack Overflow 的現(xiàn)成代碼，而是回到這三個(gè)底層原理去排查。
最后拋出一個(gè)問題供評(píng)論區(qū)討論：
在實(shí)際項(xiàng)目中，你更傾向于使用原生 Canvas 2D API 進(jìn)行復(fù)雜圖形繪制，還是直接上 WebGL/Three.js 來處理？在什么閾值下，你會(huì)決定從 2D 切換到 3D 或 WebGL 方案？歡迎在評(píng)論區(qū)分享你的經(jīng)驗(yàn)。