说实话，Canvas这玩意儿，我一开始是真没当回事。不就是个画板嘛？在网页上画点线、填充个颜色，能有多难？ 直到有一天，我要实现一个实时数据可视化，上万条数据点，每帧都要重绘…… 直接卡成PPT，帧率掉到 15fps。那一刻，我才发现自己对Canvas的理解有多浅。
后来我翻遍了MDN，看了无数Stack Overflow，终于摸到点门道。真正要命的不是API怎么用，而是浏览器底层怎么在GPU上管理这些像素。所以这篇文章，我就想聊聊那些文档里很少讲，但掉坑率极高的底层细节。不扯概念，直接开刀。
离屏Canvas：为什么不早告诉我还有这招？
大部分教程都会教你：获取context -> 绘制 -> 结束。但是，如果你需要频繁绘制复杂图形，比如仪表盘，每一帧都要重新画背景、刻度、指针。主线程直接画，画完还要触发合成，这个过程会阻塞UI交互。我当时的项目就遇到了这种问题，点击按钮要等几百毫秒才有反应。
后来发现了 OffscreenCanvas。简单说，就是把绘制工作扔到 Web Worker 里，完全脱离主线程。这意味着什么？意味着即使你画一个极其复杂的场景，主线程依然丝般顺滑。我做了个对比测试：绘制 5000 个随机位置、随机颜色的圆，传统方式在主线程上帧率只能维持在 25fps 左右；而使用 OffscreenCanvas 在 Worker 中绘制，再传回主 Canvas，帧率直接跑到 57fps，近乎满帧。数据不会骗人。
不过，OffscreenCanvas 也不是银弹。坑点之一：Worker 里没法直接操作 DOM，也没法监听鼠标事件。如果你的绘制逻辑需要实时响应用户交互，比如拖拽绘图，就必须在主线程和 Worker 之间设计一套消息通信机制。我当时的方案是用 postMessage 传指令对象，结构类似 { type: ‘draw’, x: 100, y: 200 }，Worker 解析并执行。但这里要注意，你传的对象会被结构化克隆，千万别传大块二进制数据用这种方式，要传就用 Transferable 对象，否则内存拷贝的开销反而更糟。而且，OffscreenCanvas 还能直接跟 WebGPU 结合，以后潜力巨大。但现阶段，兼容性检查必不可少，Safari 某些版本支持不完整，坑啊。
像素密度这玩意儿，坑了多少设计师？
讲个真事：设计师给了个设计稿，Canvas 尺寸 300×150，里面的文字纤细清晰。我照着写，出来效果字糊成一团。设计师盯着屏幕，眼神里充满了“你是不是在忽悠我”的怀疑。花了半天排查，结果发现是设备像素比（devicePixelRatio）的锅。视网膜屏上，1 个 CSS 像素对应 2 个甚至 3 个物理像素。Canvas 默认按 CSS 像素绘制，所以图被放大了，能不糊吗？
解决方案？老老实实写高清适配。片段如下（当然，这里我不会贴代码，但思路很简单）：先拿到 devicePixelRatio，然后设置 Canvas 的实际宽高为其 CSS 宽高乘以这个比值，再用 scale() 缩放上下文。这样绘制的图形就会利用到所有物理像素，边缘清晰锐利。但是！显存占用会急剧增加。一个 1000×1000 的 Canvas 在 2x 屏上实际占用 2000×2000 的显存，像素数量翻了 4 倍。如果你画布很多，移动端浏览器直接 OOM 崩溃不是梦。这是我踩过的第二个大坑：为了高清而高清，结果应用崩了。极限情况下，必须动态降级，根据设备性能条件判断，只对核心 Canvas 做高清处理。
GPU 加速下的“脏矩形”魔法
很多人误以为 Canvas 是“位图”，所以重绘就是全部擦掉重画。错。浏览器的底层实现远比这聪明。Canvas 2D 的很多操作实际上是 GPU 加速的，比如绘制图像、变换和合成操作，都是走 GPU 管线。但如果你不停地在 CPU 和 GPU 之间来回搬运数据，比如频繁调用 getImageData 和 putImageData，就会触发可怕的同步等待。这就是为什么有些动画没做对优化，CPU 占用会飙到 100%。
真正的优化在于“脏矩形”技术——只重绘变化的部分。比如一个游戏，背景是静止的，只有角色在动。你完全没必要每帧都清空整个画布重绘背景。可以先绘制背景到一个离屏 Canvas 上，然后每帧只需要用 drawImage 把背景拷过来，再在上面画角色。这样制图的工作量骤减。我做过一个弹幕引擎，优化前全量重绘，1000 条弹幕时帧率只有 18fps；改成只更新新增弹幕行的脏区域后，帧率稳定在 58fps。这就是工程化的力量。
第三个坑点来了：状态栈的滥用。Canvas 的 save() 和 restore() 很好用，尤其是处理复杂变换。但每帧调用几百次 save/restore，我告诉你，在移动端低端机上，这就是性能杀手。save/restore 会保存和恢复整个上下文状态（变换矩阵、裁切区域、样式等），开销不小。我曾经优化过一个图表库，发现它每次绘制数据点都会 save/restore 一次，总共上千次，移动端帧率直接个位数。后来改成只save一次，所有点用绝对坐标计算，帧率回到了 30fps。教训就是：能不用 save/restore 就不用，非得用的话，也尽量批量处理，别在循环里搞。另外，利用 requestAnimationFrame 的节流，在页面不可见时暂停绘制，也能省下不少资源。还有一个实用技巧，对于复杂场景，采用多个 Canvas 分层叠加，例如背景层、交互层、UI层，只更新变化的层，避免整体重绘，这在图片编辑器里几乎是必选方案。
说到底，Canvas 的美妙之处在于它给了你对像素的绝对控制权。这就像你拿到了 GPU 的钥匙，但能不能开好赛车，全看你对底层的理解。那些写着“简单画图”的教程，真的会误人子弟。只有亲手调过性能，排查过内存泄漏，被设备像素比折磨过，你才敢说自己“懂”Canvas。
行吧，就聊这么多。反正该踩的坑我都踩过了，现在分享出来，也算是积点德。下次再有人说Canvas简单，我就把这篇文章摔他脸上。
