Canvas适合横向卷轴跑酷、弹幕射击、物理模拟及每秒重绘数十对象的实时动作游戏，因其像素级控制、高性能渲染和无DOM开销；SVG适合交互频繁的策略类游戏UI，如点击升级塔、拖拽技能图标，依托原生事件绑定与无损缩放优势。
Canvas 更适合帧动画密集、需要像素级控制的 HTML5 小游戏；SVG 更适合交互频繁、元素需独立事件绑定或缩放不失真的轻量级游戏 UI 或策略类游戏。
Canvas 适合什么小游戏场景
当你在做横向卷轴跑酷、弹幕射击、物理模拟（如碰撞检测+粒子效果）、或每秒重绘几十个对象的实时动作游戏时，canvas 是更自然的选择。它把画布当“画纸”，你用 getContext('2d') 或 WebGL 直接操作像素，性能可控，且不产生大量 DOM 节点。
- 每帧调用
clearRect()+drawImage()/fillRect()是常规操作，但需手动管理对象生命周期和碰撞逻辑 - 无法直接给某个“敌人”绑
click事件——得靠坐标计算 +isPointInPath()或维护对象包围盒 - 导出高清图或适配不同 DPR 屏幕时，必须手动缩放
canvas.width/canvas.height并调整绘图坐标，否则模糊 - 调试困难：画上去的东西不是 DOM 元素，不能用浏览器开发者工具直接选中检查
SVG 更适合什么小游戏场景
如果你的游戏核心交互是“点一个塔来升级”“拖一个技能图标到格子”“点击地图上的可交互建筑”，那 svg 的 DOM 映射优势立刻体现。每个 <circle></circle>、<rect></rect>、<g></g> 都是真实节点，支持原生事件、CSS 动画、getBBox()、甚至 focus() 和无障碍属性。
把任意文章或文档内容转换成精美的全屏翻页 HTML 演示文件（幻灯片风格）。当用户发来一篇文章、文档链接、Markdown 内容、或粘贴的文本，并且希望生成演示用的 HTML 时触发。支持任意内容来源：iWiki 链接、KM 链接、本地文件路径、直接粘贴的文本。生成的 HTML 文件保存到本地工作区，并通过企微直接发送给用户。触发词示例：帮我把这篇文章做成PPT、转成演示文档、生成HTML幻灯片、做个演示、转成可以演示的格式、article to deck、make a slide。
- 缩放无损：
viewBox+ CSSwidth/height组合即可响应式适配，不用重算坐标 - 动画推荐用
SMIL（已废弃但兼容性好）或requestAnimationFrame改transform，避免直接改x/y属性引发重排 - 大量 SVG 元素（比如上千个
<path></path>）会明显拖慢渲染，尤其在低配安卓 WebView 中，此时不如切回canvas分层绘制 -
svg不支持阴影模糊、高斯模糊等复杂滤镜的硬件加速，filter属性在部分 iOS 版本有渲染 bug
混合使用才是常见解法
真正上线的小游戏很少只用一种技术。典型分层是：canvas 承担主游戏世界（角色、特效、背景滚动），svg 叠在上方做 UI 层（血条、按钮、技能盘、地图小雷达）——两者通过绝对定位叠加，互不干扰。
立即学习“前端免费学习笔记（深入）”；
-
canvas层设pointer-events: none，确保鼠标穿透到上层svg元素 - UI 层
svg用position: absolute+z-index控制层级，避免用transform: translateZ()引发意外合成层 - 不要用
svg画动态粒子或高速移动的子弹——哪怕只是 20 个<circle></circle>每帧更新cx/cy，也比canvas绘制慢 3–5 倍 - 若需截图分享，
canvas可直接toDataURL()；svg需先序列化为字符串再转成Blob，且内联样式和外部引用资源可能丢失
实际选型时，别纠结“哪个更现代”，先想清楚：你的游戏里，玩家最常做的三件事是什么？这三件事背后的数据更新频率、图形复杂度、交互粒度，才是决定 canvas 还是 svg 的硬指标。很多团队踩坑，是因为用 SVG 做了本该用 Canvas 的事，或者反过来——结果不是性能差，就是交互卡顿、缩放糊、调试崩溃。
