Figma 断点转 CSS Media Query：映射原理详解

快速回答： Figma 没有像 CSS 那样内置"断点"这个概念。设计师用两种方式模拟响应式：针对每种屏幕尺寸单独做一个 frame，或者用 Auto Layout 的流式缩放（fill/hug）实现完全不需要 media query 的效果。设计稿实际用的是哪种方式，决定了 CSS 输出是否需要显式的 @media 规则。

Figma 其实并没有断点

这一点值得直说，因为很多人默认理解错了：Figma 没有类似 CSS media query 那种"在这里设一个断点"的原生功能。设计师实际的做法可以归为两种模式，它们转换成 CSS 的方式非常不同。

模式一：每种屏幕尺寸单独一个 frame

传统做法是为桌面端、平板端和移动端各画一个独立的 frame，每个都在各自的宽度下手动排版。这种做法可以直接映射成显式的 CSS 断点：每个 frame 的布局变成对应 @media (min-width: ...) 区块里的样式，开发者需要决定实际的断点数值应该定在哪里（对齐 frame 的宽度，还是用 768px/1024px 这类标准断点），因为 Figma frame 的宽度只是一个整齐的设计决策，并不是 CSS 规范。

当不同尺寸下的布局在结构上确实不同——不只是重新排布，而是真的不一样（一个侧边栏在移动端变成底部导航，一个三栏网格变成重新排序过的单栏）——这种方法就是正确的选择。

模式二：流式 Auto Layout 缩放——通常不需要 media query

另一种模式依赖 Auto Layout 的缩放行为——"填满容器"和"随内容收缩"——设置在单个 frame 上，而不是在每个宽度下重新画一遍整个布局。一排设置成可换行并填满可用空间的卡片、一个固定宽度的侧边栏搭配一个"填满"的主内容区、在灵活容器内自然重新排布的文字——这些都不需要断点。这和用 flex-wrap、百分比宽度以及 min-width/max-width 在不写一行 @media 规则的情况下实现的 CSS 效果是一样的。

这一点特别值得强调，因为它对审查生成的 CSS 是更有价值的洞察：不是每一个响应式细节都应该变成一条 media query。 一个依赖 Auto Layout 流式缩放的设计，转换出来的 CSS 本身在一段宽度范围内就是自然流式的——在此之上再叠加显式断点，通常只是在多做一遍布局本来就已经具备的行为。

手动转换时常见的错误

• 在流式 CSS 已经能覆盖的地方还加断点，导致 @media 规则比设计实际需要的多得多，样式表也比布局本身合理需要的更难维护。
• 漏掉一个真正需要的断点，当设计确实有一个结构上不同的移动端 frame 时，却强行让桌面端布局重新排布成它从未被设计成的样子。
• 随意选择断点像素值，既不匹配设计本身的 frame 宽度，也不匹配项目已有的断点体系，凭空造出一个没有其他任何 CSS 会用到的数值。

MarkupGen 如何处理这一切

响应式行为是根据 frame 真实的缩放约束生成的，而不是作为单独的人工步骤额外补上——Auto Layout 的 fill/hug 设置会自动转化为流式 CSS，正是上文说明的那种区分。对于确实存在结构不同的移动端布局的设计（或者需要从单个桌面端 frame 生成出来），MarkupGen 可以生成一份独立的 AI 生成移动端或桌面端布局——具体做法可参考 Figma 响应式设计详解：Mobile 与 Desktop 布局全解析。至于这一切背后的 Auto Layout 到 Flexbox 映射关系，可参考 Auto Layout to CSS。

在你自己的设计稿上试试看

最快判断自己的设计稿实际需要哪种模式的方法，就是实际跑一遍，然后检查生成的 CSS 里有没有 @media 规则——或者压根没有。在你自己的 Figma 文件上免费试用 MarkupGen，或查看 Figma to HTML converter 页面，了解具体包含哪些内容。