Canvas不能替代DOM绑定机制，因其无元素、无事件、无语义化交互能力；它适用于高性能图形渲染，而表单、输入、无障碍等应交由DOM层处理，二者宜分层混合使用。
Canvas 替代 DOM 能显著提升性能，但前提是用对了地方——它只在「大量动态元素」或「像素级控制需求强」的场景下才比 DOM 快。盲目替换反而增加维护成本、丢失语义、破坏可访问性。
什么时候该用 Canvas 替 DOM？
核心判断标准就一条：DOM 节点是否在持续、高频地改变位置/尺寸/透明度/颜色，且数量超过 50 个。
- 适合 Canvas：200 片飘雪、1000 行实时行情表格、粒子系统、热力图、拖拽式拓扑连线（静态底图用 SVG，动态节点用 Canvas）
- 不适合 Canvas：普通按钮、表单输入框、带 focus/label/aria 的交互控件、SEO 敏感内容（如文章正文）
- 特别注意：Canvas 本身不支持键盘导航、屏幕阅读器无法解析文本内容，
canvas必须配aria-label或外挂role="img"+alt文本说明
Canvas.width / height 不匹配 clientWidth / clientHeight 就会错位
错位不是画歪了，是坐标系塌缩了。比如你在 CSS 里写 canvas { width: 100%; height: 600px; }，但没同步设置物理像素尺寸，高 DPI 屏上文字和 DOM 叠加层就会偏移。
- 必须在初始化时立刻执行：
canvas.width = canvas.clientWidth * window.devicePixelRatio，canvas.height = canvas.clientHeight * window.devicePixelRatio - 紧接着调用：
ctx.scale(devicePixelRatio, devicePixelRatio)，之后所有绘图坐标（如fillRect(10, 10, 20, 20)）仍按 CSS 像素写，不用手动乘 DPR - 叠加的 DOM 元素（如 tooltip、告警弹窗）要加
transform: translateZ(0)或will-change: transform，否则可能被 Canvas 合成层遮挡
requestAnimationFrame 里别每帧全屏 clearRect
卡顿主因不是 Canvas 慢，而是你每帧都在干三件低效的事：clearRect(0, 0, w, h)、循环中反复设 ctx.fillStyle、每个文本都调 fillText。100 次颜色切换 ≈ 30ms，直接吃掉两帧。
- 只清除变化区域：
clearRect(x, y, w, h)替代全屏清空，尤其适合局部更新（如单行表格刷新、雪花回收重置） - 批量绘制同色元素：先统一设
ctx.fillStyle = '#4a90e2'，再一口气画完所有矩形或圆点 - 文字复用样式：提前设好
ctx.font和ctx.textAlign，避免每行都重设 - 固定标签（如“CPU 使用率：”）可缓存为离屏
canvas，运行时用drawImage复用
Canvas 拦截鼠标事件导致底层 SVG/DOM 点不到
Canvas 默认吃掉所有 pointer 事件，哪怕它只是盖在 SVG 上面，底层 hover、click 都会失效——这不是 bug，是浏览器合成层默认行为。
- 绝大多数场景下，直接给
canvas加style="pointer-events: none"，让事件穿透到底层 - 需要 Canvas 响应交互时（如拖拽热力图），临时切回
pointer-events: auto，再用canvas.getBoundingClientRect()+event.clientX/Y手动映射坐标 - 确保 SVG 内部节点显式声明
pointer-events="visiblePainted"，否则fill="none"的路径或空
真正难的不是写 Canvas 动画，而是判断哪些东西该交给 Canvas、哪些必须保留在 DOM。坐标系对齐、事件穿透、DPR 适配、局部清除——这些细节一旦漏掉一个，性能优势就立刻被抵消，甚至更差。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
