Figma 转 CSS：实用转换指南

快速回答： 把 Figma 转换成纯 CSS，意味着把 Auto Layout 翻译成 Flexbox，把每一个填充色、间距、文字数值都解析为真实的具体数字，而不是近似的工具类，并且让输出结果不依赖任何框架。当你想完全掌控每一条规则、不想再学习、安装或日后覆盖某个框架时，这就是正确的输出目标。

为什么选纯 CSS 而不是框架

MarkupGen 支持的每一种输出格式——纯 CSS、Tailwind、Bootstrap、Bulma——都源自同一份数据：Figma frame 的真实结构和数值。纯 CSS 只是其中最"直接"的一种格式，你的文件和浏览器之间没有任何中间层：

• 没有类命名规范要学。 Tailwind 的工具类体系和 Bootstrap 的组件类都很强大，但终究是需要内化的一套系统。纯 CSS 只需要懂 CSS 本身。
• 没有框架体积负担。 即便做了未使用类的清理，框架依然会带来构建步骤和需要持续维护的依赖。纯 CSS 导出两者都没有。
• 每一条规则都可以原地修改。 改一个间距值，只需要编辑一条声明，不用去查哪个工具类对应你想要的那个像素值。

代价正是 Tailwind 存在的原因：没有框架强制规定一套取值体系，随着代码库不断增长，如果没有人自律地复用相同数值，间距和颜色就可能逐渐失去一致性。对单个落地页或小型网站来说，这很少构成问题。但对有多人协作的大型产品，值得先读一读 纯 CSS vs Bootstrap vs Tailwind 再做决定。

实际需要转换的内容

一个 Figma frame 携带的结构信息，比乍看之下要多得多，每一部分都对应 CSS 中特定的一块：

这些都算不上什么冷门操作——正是开发者手动逐像素还原设计稿时会做的同一套映射。区别在于：这是基于 frame 真实的结构和数值完成的，而不是靠肉眼判断一张截图。

MarkupGen 如何生成 CSS

无论选择哪种输出格式，工作流程都是相同的四步：用 MarkupGen 插件从 Figma 导出 frame，插件会一并捕获结构、样式和图片；AI 基于这份真实结构而不是近似猜测一张图片来构建标记代码；如果有需要，可以在应用内编辑器里调整内容、字体或布局；最后导出最终的代码包。

对纯 CSS 输出来说，这意味着生成的样式表使用的是 frame 真实的颜色和间距数值，而不是把它们对齐到某个框架预设的取值档位——一个设为 #3B82F6 的填充色，输出出来就精确是这个值，而不是最接近的 Tailwind 蓝色。Auto Layout 会自动映射为 Flexbox 结构（完整的逐属性对照可参考 Auto Layout to CSS），响应式行为也是根据 frame 的缩放约束生成，而不是作为单独的人工步骤额外补上。默认输出的 HTML 更倾向使用语义化元素而不是层层嵌套的 <div>，这对可维护性的意义，不亚于它对无障碍访问和 SEO 的意义。

把 Figma 变量转换为 CSS 自定义属性

Figma 的变量（颜色、字体、间距、圆角、效果）是设计文件中最接近"设计系统"的部分，从概念上看，它们对应的正是 CSS 自定义属性——一个由 --name: value 键值对组成的 :root 代码块，样式表里的每一条规则都可以引用它。如前所述，MarkupGen 目前的 CSS 输出会把每个属性解析成每个元素上的具体数值，而不会自动生成那层 :root 变量，所以搭建这套映射需要手动完成。不过一旦掌握了规律，这其实是一项机械性的工作：

有一条命名约定值得坚持：直接沿用 Figma 变量自身的分组/名称结构（color/primary → --color-primary），而不是另起一套并行的命名方式，这样即使设计后续迭代，两边也始终便于对照。一旦这些变量以自定义属性的形式存在，就可以把导出 CSS 中生成的具体数值替换为 var(--color-primary) 这样的引用。

在依赖这套方法之前，有两个局限性值得了解：并非每个 Figma 变量都能干净利落地对应到单一的 CSS 属性——一个在设计中的不同位置既用作边框颜色又用作文字颜色的变量，如果这两种用途本质上并不相关，也不意味着在代码里就应该把它们绑定在一起。另外，响应式变量（比如在不同断点之间会变化的间距值）需要在每个相关的媒体查询里重新声明，因为单个 :root 自定义属性同一时刻只能保存一个值——Figma 里按断点划分的多个 frame，并不会自动转化为 CSS 中基于层叠机制的响应式覆盖规则。

上线前审查生成的 CSS

• 排查数值漂移。 由于没有工具类体系强制保证一致性，要留意那些几乎相同却略有差异的数值（比如某处是 padding: 15px，别处却是 padding: 16px），它们很可能本该是同一个数字。
• 在真实断点下确认响应式表现，而不只是看 frame 的默认尺寸——动手调整浏览器窗口，而不是只信任一张截图。
• 检查类名/选择器命名，如果项目有自己的命名规范要遵循（BEM、CSS Modules 等），在合并前先做调整。
• 用应用内编辑器做内容或布局上的调整，而不是手动改动导出的代码，改完后重新导出，避免两边不同步。

每次导出还会自动获得一个 AI 质量评分，把实时预览和原始设计做对比，让你在人工审查之前就能有一个快速的上线信号。

常见问题

CSS 输出会用到 CSS 自定义属性（变量）吗？ 输出以标准的、可直接编辑的逐元素规则为主，而不是一套基于变量的主题层——如果你的项目本身用的是自定义属性体系，需要把生成的数值手动整合进去。

布局默认就是响应式的吗？ 是的——断点是根据 frame 的 Auto Layout 缩放约束生成的，而不是后期补加的。想了解这在独立的移动端/桌面端布局之间是如何运作的，可参考 Figma 响应式设计详解：Mobile 与 Desktop 布局全解析。

这和 Tailwind 输出有什么不同？ 数据来源相同，落地方式不同：Tailwind 输出会把数值解析成最接近的工具类（超出取值范围时回退到任意值类）；纯 CSS 输出则把设计的精确数值保留为标准声明。具体选哪种，取决于你的项目是否已经统一使用某个工具类框架。

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

如果你还在纯 CSS 导出和基于框架的导出之间犹豫，最快的判断方式就是在同一个设计稿上分别看一看两者的效果。免费试用 MarkupGen，或者阅读完整的 Figma 转 HTML 转换指南。想先快速了解一下？可以看看 Figma to CSS converter 页面。