HTML to Canvas：位图截图与可编辑 Figma 图层的区别

“HTML to canvas”是那种因搜索者不同而含义完全不同的说法。前端开发者通常指的是把 DOM 元素渲染到 HTML <canvas> 中——这正是 html2canvas 这类库的工作。设计师通常指的是把网页放到 Figma 画布上，以便在上面继续设计。

两者都从 HTML 出发，最后都落在一个叫“canvas”的东西上。但结果有本质区别：一个是扁平的像素网格，另一个是可编辑的图层树。选错了会浪费时间，所以值得把概念说清楚。

含义一：HTML 转 HTML <canvas>（位图）

工作原理

HTML <canvas> 元素是一个绘图表面：一块可以用 JavaScript 绘制的像素矩形。html2canvas 等库会遍历 DOM，读取计算样式，再用 Canvas 2D API 把页面重新绘制到 canvas 上。输出是一张可导出为 PNG 或 JPEG 的位图。

相关方法产出的结果也属于同一类：

• 浏览器截图——浏览器自带的截图功能、DevTools 的“Capture node screenshot”，或无头浏览器截图。
• SVG foreignObject 技巧——把 HTML 嵌入 SVG，再绘制到 canvas 并导出像素。
• 服务端截图服务——由无头浏览器渲染页面并返回图片。

什么时候位图是正确选择

当图片本身就是交付物时，位图确实很有用：

• “分享为图片”按钮——图表、收据、引言卡片。
• 在不同构建之间比对像素的视觉回归测试。
• 缩略图和社交分享预览图。
• 需要准确展示用户所见内容的缺陷报告。
• 存档页面在某个时间点的样子。

在这些场景中，没有人需要编辑结果，只需要看。

位图的局限

一旦你想在捕获的页面上继续工作，像素就会成为障碍：

• 无法编辑。 你不能修改标题、调整间距或更换颜色，只能在上面涂改。
• 没有文本。 文字就是像素。你无法选中、搜索、查看字号，也无法复制到规格文档中。
• 缩放后模糊。 位图分辨率固定。放大查看，或把 1x 截图放到高像素密度屏幕上，边缘就会变虚。
• 没有结构。 没有框架、没有层级、没有可检查的间距数值。按钮和它背后的背景是同一个图层。
• 没有响应式。 1440 宽的截图永远只有 1440。每个宽度都需要单独截图，而且都无法有意义地调整尺寸。
• 没有设计系统。 颜色和字体无法转为变量或样式，重复元素也无法变成组件。
• 还原度差异（针对重绘类库）。 把 DOM 重绘到 canvas 的库是用 JavaScript 重新实现 CSS 的，因此较新或不常见的 CSS 特性可能与真实浏览器渲染得不一样。

含义二：HTML 转到 Figma 画布（可编辑图层）

工作原理

在 Figma 中，“画布”是放置框架的无限工作区。把 HTML 放到 Figma 画布上，意味着把渲染后的页面转换为 Figma 原生对象：框架、文本图层、矢量和图片填充。

这正是 HTML to Frames 所做的。页面在真实浏览器中渲染，测量其几何信息和计算样式，然后插件在 Figma 中将其重建为：

• 与页面结构对应的嵌套框架，并在可校验之处应用自动布局（Auto Layout）；
• 支持混合样式、字间距、行高和链接的真实文本图层；
• 作为可编辑矢量的 SVG；
• 遵循 object-fit 和 background-size 的图片填充；
• 作为原生属性的边框、圆角、阴影、渐变、模糊和混合模式。

得到的是可以编辑、重新设置样式、调整尺寸和组件化的内容——不是一张页面图片，而是一个可用的设计文件。HTML to Figma 指南介绍了完整的导入流程。

什么时候可编辑图层是正确选择

• 以现有网站为起点的改版设计。
• 对间距、字体和颜色的设计审查。
• 提取设计系统——颜色变量、文本样式和阴影样式（Pro）。
• 对代码实现页面的交付与评审，包括通过 Chrome 扩展捕获的 localhost。
• 打磨通过 MCP 导入的 AI 生成 UI——参见 AI to Figma。
• 响应式工作——一次导入即可获得 Desktop、Tablet 和 Mobile。

对比一览

一句话总结：html2canvas 给你像素；HTML to Frames 给你 Figma 画布上的图层。

为什么在真实浏览器中渲染很重要

两种方法都首先取决于页面渲染得有多忠实。html2canvas 这类重绘库在页面内运行，用 JavaScript 重新实现 CSS 布局和绘制。对常见样式效果不错，但凡是库没有实现——或实现略有不同——的部分，都会在图片中表现为偏差。

HTML to Frames 走的是另一条路。公开页面、本地文件和粘贴的代码在隔离的沙盒浏览器中渲染，而通过 Chrome 扩展捕获的页面则来自你自己的浏览器。无论哪种方式，插件读取的都是浏览器实际生成的几何信息和计算样式，再将其重建为 Figma 对象。因此，那些容易出错的细节都能正确还原：

• 与 Chrome 一致的列表标记、CSS 计数器、上标和下标。
• 渐变——线性、径向和锥形，包括 px 色标以及重复或平铺渐变。
• 来自 srcset 的高分辨率图片，并遵循 object-fit、background-size 和平铺。
• 单独一侧颜色不同的边框、内阴影和外阴影，以及 text-shadow。

页面还会按普通访客看到的样子被捕获：可按需隐藏 Cookie 横幅和弹窗，动画会被冻结，从而得到干净的画面，而不是停在过渡中途。

那些本来就是 canvas 的内容怎么办？

这正是两种含义交汇的地方。网页的某些部分本质上就是像素，任何转换器都无法把它们变成有意义的矢量图层：

• 绘制在 <canvas> 中的 WebGL 和 3D 场景；
• 2D canvas 绘图，例如某些图表或游戏；
• iframe，包括嵌入的地图；
• 没有封面图的视频；
• object 和 embed 元素。

HTML to Frames 以务实的方式处理它们：每一个都以仅该区域的截图图片形式导入。图片位于正确的位置、尺寸正确，而页面其余部分完全可编辑。你的首屏标题、导航和卡片仍是真实图层；只有 3D 产品查看器或嵌入地图是位图。

对于动画内容，捕获力求得到干净、稳定的画面：动画会被冻结，WebGL 在渲染几帧后冻结，让场景在被捕获前有时间渲染出有意义的内容。

这种混合方式通常正是设计师想要的。你不会去重新设计嵌入地图的内部，而是设计包裹它的卡片。嵌入内容用截图占位，其余一切可编辑，这就是实际可用的结果。

暂未支持转换的内容

完整说明一下限制：倾斜（skew）和 3D CSS 变换、path() clip-path、多层遮罩以及 Display-P3 颜色暂不支持。CSS 旋转和缩放、单个 clip-path 形状、mask-image、模糊和背景模糊均已支持。完整列表见功能页面。

选择合适的方式

只需问一个问题：会有人编辑这个结果吗？

1. 不会——用于查看、分享或测试。 用位图。html2canvas 或浏览器截图更简单、更快。
2. 会——用于设计工作。 用 Figma 画布上的可编辑图层。
3. 大部分会，但其中有地图、视频或 3D。 用可编辑图层；这些区域会自动以图片形式导入。

几个实际场景：

• “我需要这张图表的 PNG 放进幻灯片。” 位图。
• “我需要重新设计我们的价格页。” 可编辑图层——导入后再迭代。
• “我想把线上版本和我们的设计稿做对比。” 可编辑图层，并使用可选的 Reference screenshot（参考截图，Pro）——一个隐藏、锁定的图片图层，可随时打开做像素级对比。这是两种含义协同工作的好例子：位图用于核对，图层用于工作。
• “我需要把登录后的仪表盘放进 Figma。” 通过 Chrome 扩展获得可编辑图层，它能捕获你浏览器可见的页面，包括其当前状态。

为什么“截个图就行”之后代价更高

截图感觉更快，因为几秒钟就能完成。代价会在之后显现：一旦真正的设计工作开始，就得有人手工重建每个框架。从像素中量内边距、猜字号、重新输入文案、重建颜色——每个页面累计下来就是好几个小时。

转换为可编辑图层，就把这些工作交给了工具。你会得到实测尺寸、真实文本，以及——使用 Pro 时——直接从页面生成的变量、文本样式和组件。HTML to design 工作流展示了这在一次完整改版中的样子。

隐私说明

无论选择哪种方式，都要考虑页面在哪里渲染。html2canvas 在用户浏览器的页面内运行。HTML to Frames 在隔离的沙盒浏览器中渲染公开页面，结果只交付一次，随后从内存中删除，不会写入磁盘；Chrome 扩展在你自己的浏览器中运行，除非你使用 Send to Figma，否则不会发送任何内容。详情见安全页面。

总结

• **HTML to canvas（位图）**把页面变成像素。适合分享、测试和预览；不可编辑。
• HTML 转到 Figma 画布把页面变成你可以继续加工的框架、文本和矢量。
• 本身就是 canvas 的内容——WebGL、地图、iframe、无封面图的视频——会以该区域的图片形式捕获，其余部分保持可编辑。

想在你自己的页面上体验基于图层的方式，请获取插件并从文档开始，或阅读自动布局引擎如何把页面结构转换为框架。