为什么导入网页后 Figma 的 Auto Layout 会错位

浏览器里齐平的一排卡片，进了 Figma 有一张低了四个像素。哪一处都没坏到能指出来。这篇讲的是到底发生了什么。

你把一个网页导入 Figma，图层面板填满了，但总觉得哪里不对。浏览器里齐平的一排卡片，现在有一张往下掉了四个像素。原本居中的导航栏，现在是"大概居中"。哪一处都没坏到能指出来，可这个文件已经跟你旁边开着的截图对不上了。

这几乎总是 Auto Layout，被套在了不该套的地方。值得弄清楚原因，因为解决办法不是"关掉 Auto Layout"，而是分辨两套布局系统何时真正一致、何时是工具在猜。

两套本来就不该一致的布局引擎

浏览器用 CSS 排版。Flexbox、Grid、float、行内流、外边距合并、把文字挤出自身盒子的 line-height、各平台不同的次像素取整。几十年积累的规则，其中大部分是只会遇上一次的边界情况。

Figma 用 Auto Layout 排版。这是个小得多的系统，而且是刻意如此：一个方向、一个间距、四个内边距、两个轴上的对齐，加上每个子元素的 grow 和 stretch。基本就这些。

Auto Layout 不是 flexbox 的重新实现。它像 flexbox 的程度，跟自行车像摩托车差不多。所以当转换器读到 display: flex 就写下 layoutMode: "HORIZONTAL"，它其实是在断言一件事：这两套系统会把每个子元素放在同一个位置。有时候是真的。更多时候是"差不多是真的"，而那更糟。

两者悄悄分岔的地方

下面这些看着都像 flexbox，Auto Layout 一个也复现不了。

• flex 子项上的外边距。 CSS 里子元素可以带自己的 margin，包括用 margin-left: auto 把一组元素推到右边。Auto Layout 只有整个 frame 共用的一个间距，根本没有单个子元素的外边距。
• space-around 和 space-evenly。 Auto Layout 有的是 SPACE_BETWEEN。另外两种分配剩余空间的方式不同，而且没有设置能复现它们。
• align-items: baseline。 不同字号的文字落在同一条基线上，标题和价格行里很常见。Auto Layout 按盒子的边和中心对齐，不按基线。
• 带小数的 flex-grow。 flex: 1 能对应到 layoutGrow: 1。flex: 2 和 flex: 0.5 没有对应物。
• flex-wrap。 换了行的一排和单行是完全不同的几何结构，而在哪里换行取决于捕获那一刻的容器宽度。
• 文字重新测量。 这一条最常把工具绊倒。随内容自适应的文字图层是 Figma 自己量的，用 Figma 手上的字体，按 Figma 算出的字号。只要这个测量结果跟浏览器差一个像素，堆叠中排在它后面的所有同级元素都会移位。

正因为最后这一条，这个问题往往要等你装上缺失的字体之后才出现，或者只在别人的电脑上出现。

那为什么转换器还是照套不误

因为一个满是 Auto Layout frame 的文件，看起来比满是绝对定位矩形的文件更像好产品。演示时好看，功能列表上能多一条。而且在常见情况下——一排简单的行、间距均匀的卡片网格——它确实更好：你缩放 frame，它会正常响应。

问题在于，不去核对就分不清"常见情况"和"差一点点"，而核对比不核对费事。

该怎么办

如果已经导入了

选中看起来不对的 frame，把布局模式设成无，在 Figma 右侧面板的布局区。子元素会保持当前位置，所以如果位移已经发生，这么做是把它冻结而不是撤销。因此真正管用的办法通常是重新导入，而不是修补。

动手之前先确认一件事：这个页面用的字体，你机器上装了吗？字体被替换会让每个文字图层重新测量，而文字宽度不对的文件，怎么调布局都救不回来。打开文件时 Figma 会告诉你缺哪些字体。

如果你正在挑工具

问它：两套系统不一致的时候你怎么处理。可能的回答只有三种，其中只有一种站得住。

1. 看到 flexbox 就一律套上 Auto Layout。 快，演示好看，然后交给你一个悄悄错位的文件。
2. 从不套用。 永远正确，永远没用。你会拿到一堆绝对定位的图层，精确但编辑起来很痛苦。
3. 只在能复现原样时才套。 既正确又有用，但要求工具真的去预测 Figma 会怎么做，然后比对。

Snapture 怎么判断

Snapture 选第三种，机制一段话就能说清。

捕获的时候它已经知道每个元素在哪，因为它读的是渲染后的页面：每个子元素都有浏览器算出来的真实矩形。在套用布局之前，它会模拟 Figma 引擎处理同一个 frame 会怎么做——内边距、间距、对齐、grow 的分配——为每个子元素算出一个预测矩形。然后比对两组结果。如果每个子元素都落在浏览器所放位置的 半个像素 以内，就套用布局；只要有一个没落进去，整个 frame 就保留精确的绝对坐标。

另一头还有第二道检查。Figma 插件套用布局之后，会再量一次子元素，这次对的是真引擎而不是预测；如果有任何东西超出同样的半个像素，就把这个 frame 退回到捕获时的坐标。这道检查之所以存在，是因为文字图层可能在导入时以任何模拟都预见不到的方式被重新测量。

实际比例是这样

把转换器跑在真实页面上，能看出它有多挑剔。这些是实测页面上同一次测量的数据。

有意思的是 MDN 这一行。253 个节点里只有 5 个 Auto Layout frame，看着像工具失灵。那是工具在正常工作：MDN 的正文排版主要是文档流和 float，Auto Layout 压根不建模这些，所以关卡几乎全部拒绝，保留了精确坐标。对那个页面来说，这才是对的取舍。

Linear 则相反，几乎整站都由间距均匀的 flex 行搭起来。它有 261 个 frame 真正通过了比对，而这些 frame 在 Figma 里缩放时表现正常。

简单说

导入之后的 Auto Layout，只有在有东西验证过的前提下才值得信。Flexbox 和 Auto Layout 相似到足以骗过转换器，又不同到足以让你的文件挪位，而且这个差别通常表现为几个像素而不是明显的破损——恰恰是最费时间去找的那类错误。

如果一个工具说不出两者不一致时它做什么，那就当它不会去核对。

English · 한국어 · 日本語 · 简体中文 · 繁體中文 · Español · Português · Français · Deutsch · Русский · Italiano · Bahasa Indonesia