用了三年CSS Grid，我今天才发现以前理解布局的方式全是错的

原创于 2026-07-02 09:49:47 发布 · 113 阅读

0 ·

本内容遵循CC 4.0 BY-SA版权协议

GEO检测

收录于

figma

话题

#「谁说嵌入式只是调包和焊板子？」—— 2026嵌入式全栈技术征锋令

上周我在重构一个项目，需要参考一个竞品网站的卡片布局。

那个网站用了复杂的 Grid 嵌套，里层还有 Subgrid。打开 DevTools 一看——Elements 面板里 grid-template-columns 写了三行，还有 gap、grid-column、grid-row 各种属性。我盯了五分钟，脑子里画不出这个布局到底长什么样。

这不是我一个人的问题。CSS Grid 已经普及好几年了，但真正能在脑子里"看见"Grid 布局的人不多。你看到一串代码：

css

.grid-container {
  display: grid;
  grid-template-columns: 2fr 1fr 1fr;
  grid-template-rows: auto 1fr auto;
  gap: 24px 16px;
}

你知道它定义了一个三列两行的网格。但"它在这个页面上到底长什么样、卡片之间是不是真的对齐了、我在这个布局里再加一个元素会去哪"——这些问题的答案，不在代码里，在你的空间想象力里。

后来我换了个方法去理解那个竞品的布局。用 DrawFlare 把它导进了 Figma，然后在 Figma 里看它的自动布局参数。

这下看清楚了。原来不是我以为的那种排列方式。

一个前端用 Figma 看布局，到底在"看"什么

先说清楚：DrawFlare 做的事情不复杂。装个 Chrome 扩展（点这里直达）点一下导出网页，再装个 Figma 插件（点这里直达）导入，网页就变成可编辑图层了。但当你从一个"写代码的人"的视角去看这个 Figma 文件的时候，你会发现一些在 DevTools 里不容易看到的东西。

Grid 布局变得看得见了。

在 DevTools 里，Grid 的 overlay 确实能帮你看到网格线。但它的问题是：你得先把代码写出来，才能看到 overlay。你是"先写再验证"的逻辑。

在 Figma 里是反过来的。你能直接「看到」这个网页的布局结构。导航栏是一个 Frame，Feature 区域是一个嵌套的 Auto Layout Frame，卡片之间的间距直接标注成数字。你不需要在脑子里组合那些属性，Figma 帮你展示出来了。

我曾经导入过一个用了 Subgrid 的页面。那个页面有一组卡片，每张卡片内部有三行文字，三行文字之间的间距通过 Subgrid 跟父容器保持一致。在 DevTools 里我看懂了每一行代码的作用，但我花了很久才在脑子里拼出"这三行文字跟父容器里的其他元素是怎么对齐的"这个画面。在 Figma 里，选中那个卡片，选中那三行文字，它们的排列关系一目了然。

Auto Layout 参数直接对应现代 CSS。

Figma 的 Auto Layout（自动布局）这个概念，跟 CSS 的 Flexbox 和 Grid 在逻辑上是高度对应的。

padding → 对应 CSS padding
item spacing → 对应 gap
horizontal/vertical → 对应 flex-direction
hug / fill → 对应 width: fit-content / flex: 1

所以当你把网页导进 Figma 之后，看到的 Auto Layout 参数可以直接翻译成 CSS：

Figma Auto Layout 参数：
padding: 24px
item spacing: 16px
direction: horizontal
alignment: center

→ CSS
.container {
  display: flex;
  gap: 16px;
  align-items: center;
  padding: 24px;
}

不需要翻 DevTools，不需要在 Computed 里找半天。看一眼，直接写。

复杂嵌套层的结构一眼看穿。

最让我觉得值的是这个。当你要理解一个有四五层嵌套的容器结构时，在 DevTools 的 Elements 面板里一层层展开，每一层的 padding、margin、border 都在不同的节点上。你要么手动算总间距，要么开了好几个面板来回切。

在 Figma 里，嵌套的 Frame 结构在图层树里直接展开，每一层的内边距"堆叠"在一起。你选中最里面的那层，外层容器的间距也能看到。不用算，不用切，视觉上就能理解这个结构的"承重墙"在哪里。

对 CSS 新特性的支持，比我想象的好

我本来以为这种工具对最新的 CSS 特性支持会不怎么样，毕竟它们更新速度很快。但实测下来，DrawFlare 在几个重要的现代 CSS 特性上表现不错。

Container Queries

Container Queries 现在已经很常用了。我测了一个用了容器查询的组件——一个 Dashboard 卡片，它会根据父容器的宽度调整自身的布局。DrawFlare 导出来后，卡片的不同状态在 Figma 里被识别成了不同的 Frame 变体。虽然不能直接看到"当容器宽度小于 600px 时切换到竖排"这个逻辑（这个毕竟没法在静态的 Figma 里体现），但不同尺寸下的布局状态被完整保留了。

这就够了。我不用在浏览器里拉伸窗口去看它怎么变，我直接在 Figma 里看到它"窄版本"和"宽版本"的对比，然后在代码里写对应的 container query 就行。

嵌套 CSS 和 Layers

现在写 CSS 都会用嵌套语法了。DrawFlare 不处理你写了什么语法，它只关心浏览器最终渲染出来的东西。所以不管源代码是嵌套写法还是普通写法，导出来效果一样。这一点对前端来说是好事，意味着你不需要担心"我的写法它认不认识"。

CSS Layers（@layer）也是一样。多层叠优先级规则在渲染之后已经变成确定的视觉结果了，DrawFlare 只是拿到这个结果。你看到的是"哪个元素的颜色在前"而不是"哪一层 @layer 的优先级更高"。

Design Tokens 的逆向提取

这个算是我觉得最实用的功能之一。很多网站现在都用设计令牌来管理样式——一组预定义的色板、字号、间距值。当你把网页导进 Figma 之后，这些值全部散落在图层的属性里。你可以做一件事：把所有的颜色值、字号值、间距值收集起来，做成自己的 CSS 变量表。

css

/* 从 Figma 里提取出来的设计令牌 */
:root {
  /* 颜色 */
  --color-primary: #4F46E5;
  --color-secondary: #818CF8;
  --color-surface: #FFFFFF;
  --color-text-primary: #1F2937;
  --color-text-secondary: #6B7280;

  /* 间距 */
  --space-xs: 4px;
  --space-sm: 8px;
  --space-md: 16px;
  --space-lg: 24px;
  --space-xl: 32px;

  /* 字号 */
  --text-xs: 12px;
  --text-sm: 14px;
  --text-base: 16px;
  --text-lg: 20px;
  --text-xl: 24px;
  --text-2xl: 32px;
}

不只是抄颜色——你能看到这个网站的设计体系到底是什么样的。它的间距是用 4px 的倍数还是 8px 的倍数？它的字号比例是 1.25 还是 1.333？这些信息，在 DevTools 里散落在几十个不同的元素上，在 Figma 里集中在一起，一次性提取。

CSS 嵌套层级和 BEM 命名

还有一个顺手的小功能：DrawFlare 保留的图层名用的是网页里原始的选择器名称。.card__header、.pricing-card、.navbar__link--active 这种 BEM 命名的样式，在图层里直接能看到。如果你要分析别人的 CSS 架构是怎么组织的，这个比翻源码快多了。

我现在用它的方式

以前我接到"参考这个网站"的需求，打开两个窗口——左边浏览器，右边 VS Code。在浏览器里看样式，切换到编辑器里写代码。遇到复杂布局就得反复切。

现在我的工作流变成了三层：

浏览器（打开参考网页）
    → DrawFlare 导出到 Figma（2秒）
        → Figma 里分析布局结构（5分钟）
            → VS Code 里写代码（带着对结构的完整理解）

Figma 文件一直开着当参考，但不是当图来看。我是把它当"布局说明书"——选中一个区域看间距，选中一行文字看字号，选中一个按钮看颜色的完整层级。所有的测量和对照都在 Figma 里完成，不需要再切回浏览器查 DevTools。

这个变化的核心价值，与其说是省了时间，不如说是减少了一次上下文切换。

前端写代码的时候，最贵的成本不是打字，是你从"看"切换到"写"的时候脑子里需要保持的那部分状态。每切一次浏览器，状态就丢一部分。DrawFlare 让我把这部分"看的操作"统一到了 Figma 里，上下文切换从"反复切"变成了"看一眼隔壁窗口"。

在团队里用的场景

最近我们在搭一个新的组件库，需要参考几个优秀的页面来定义基础的间距和字号体系。我们在 Figma 里建了一个文件，里面放了从几个参考网站导出来的设计稿。每个设计稿旁边标注了提取出来的颜色值和间距值。

前端团队直接在 Figma 里看这些参考，不用每个人都去打开浏览器、找参考网站、翻 DevTools。所有人在同一个文件里讨论"这个页面的字号比例比那个页面舒服在哪里"，效率比之前高了不知道多少。

而且因为是 Figma 文件，设计师也可以直接参与——他们能在图层上直接标注、画辅助线、提修改建议。以前设计师和前端之间"用设计稿沟通"这件事，现在变成了"用参考页面沟通"。

几个在实际使用中要注意的事

用了几个月，说几个我觉得需要注意的：

1. 动效和交互需要单独处理。 DrawFlare 只抓静态的视觉结构。如果你需要分析动画的时间曲线、hover 状态的过渡效果，还是得在 DevTools 里看。不过动效本身也不是从别人网站上"扒"来的东西，它应该是你自己设计的。

2. 图片资源需要替换。 网页里的图为了加载速度都是压缩过的。导进 Figma 之后会糊，我一般记一下尺寸比例，去素材站找高清版替换。如果你要做精细的展示页，这一步省不了。

3. 复杂交互组件只看初始态。 下拉菜单、弹窗、分页器这些带 JavaScript 状态的东西，导出后只保留初始状态的 HTML 结构。交互行为不保留，这是 Figma 本身的限制，不怪工具。

4. 不是所有 CSS 属性都能 100% 映射。 一些比较新的或者比较少见的 CSS 属性，比如 backdrop-filter、clip-path 这些，有时会有偏差。我遇到的比例不高，大概 5% 左右。

最后

前端这个行业有个特点：工具更新比人的习惯更新快得多。

CSS Grid 出来的时候，很多人还在用 float 布局。Container Queries 出来了，很多人还在写媒体查询。这些"新东西"其实不是难，是你需要一种新的方式去"看见"它们——看到它们的结构、它们在页面上怎么工作、它们跟老方法有什么不同。

DrawFlare 对我最大的帮助，不是省了扒样式的时间，而是让我更直观地理解现代 CSS 布局的工作方式。不用先在脑子里"翻译"代码再拼出画面，直接看到画面，然后去写对应的代码。

有时候一个好的工具就是这样。它没有替你做什么了不起的事，但它把"理解"这件事变得容易了。

文中的工具：DrawFlare / Web to Design

Chrome扩展安装：https://chromewebstore.google.com/detail/web-to-design/piinloombhnpicloejgbdffcdohmkofl
Figma插件安装：Web to Design - Turn websites into Figma designs | Figma
免费版：10次/月，日常够用
Pro版：$10/月，无限导入

标签

#css #前端 #figma #chorme #插件