Figma设计交付给前端前要检查哪些状态

设计稿交付前端之前，最容易出问题的往往不是“好不好看”，而是“能不能用”。前端拿到文件后，第一件事通常是照着还原，如果按钮只有默认状态、没有悬停和禁用，移动端宽度下布局直接错乱，图标和颜色又各取所需，那开发就得反复回来问。与其让这些问题在开发阶段暴露，不如在交付前把状态、尺寸、变量和响应式规则逐项过一遍。

先确认组件状态是否完整

一个按钮在页面上看起来没问题，不等于开发能直接实现。前端需要知道这个按钮在鼠标悬停、点击、禁用、加载中、出错时分别长什么样。设计稿里如果只画了默认状态，开发就只能自己猜，或者干脆不做交互反馈，最后验收时才发现体验缺失。

检查时可以把页面里出现过的交互组件列出来，逐个确认状态是否齐全。常见需要覆盖的状态包括：默认、悬停、按下、禁用、加载中、错误提示。不是每个组件都需要全部状态，但凡是用户可能触达的，至少要有对应的视觉定义。比如表单输入框要有聚焦和错误状态，下拉菜单要有展开和空选项状态，弹窗要考虑关闭按钮的悬停反馈。

判断标准很简单：如果这个组件在真实使用中会因用户操作而改变外观，那设计稿里就应该有对应的状态说明。没有画出来的状态，前端默认不会做，这不是开发偷懒，而是交付物本身没有给出指令。

长文本和空数据是两种最常见的“意外”

很多设计稿在填充内容时用的是精心挑选的短文案，看起来整齐干净，但真实用户输入的内容不会这么听话。标题可能很长，按钮文字可能超出容器，列表项可能换行后把布局撑破。交付前需要把关键位置的文本换成极端情况测试一下，比如最长的用户名、最长的商品名、最长的地址信息，看看布局是否还能保持稳定。

空数据是另一个容易被忽略的场景。页面第一次加载、用户还没有产生任何操作时，列表区域是空白的，这时候应该显示什么？是简单的“暂无数据”文字，还是配一个插图和引导按钮？如果设计稿里没有定义空状态，前端通常会留白，用户看到的就是一块没有解释的空白区域，会误以为页面出错了。

检查方法是在设计稿中主动模拟这些条件：把文本拉长、把内容删空、把图片替换成加载失败的占位符，看页面结构是否依然合理。设计时就要考虑内容的边界情况，而不是只画理想状态。

窄屏适配不是“缩小一点”那么简单

页面从桌面端缩到移动端，不是把宽度改小就结束了。导航栏可能要从横向排列变成汉堡菜单，多列布局要变成单列，表格可能要横向滚动或者重新组织信息层级。这些变化需要设计稿明确标注，而不是让前端自己判断。

交付前要确认的是：哪些组件在窄屏下需要改变排列方式，哪些可以保持原样只是缩小间距，哪些需要隐藏或折叠。最好把断点规则写清楚，比如在什么宽度范围内采用什么布局。如果项目资源有限，至少要保证主要操作路径在窄屏下可用，次要信息可以折叠或延后展示。

检查时可以模拟几种常见屏幕宽度，看看文字是否过小、点击区域是否过窄、横向滚动是否难以避免。移动端的误触问题也要考虑，按钮和链接的间距如果太近，用户很容易点错。

颜色和字号要能追溯，而不是随手取

设计稿里如果每个元素的颜色都是直接取色、没有命名，前端开发时就会面临两个问题：一是不知道哪些颜色是同一个语义，二是后续要改主题色时得一个一个找。使用颜色变量和字号变量，相当于给设计稿建立了“可维护性”的基础。

检查时看设计文件的样式面板，确认主要颜色是否建立了样式或变量，字号是否有统一的层级定义。不需要所有颜色都建变量，但品牌色、功能色（成功、警告、错误）、文字主色和辅助色，这些高频使用的值应该统一管理。前端拿到带变量的文件，可以直接对应到代码里的设计令牌，减少沟通成本。

字号同理，标题、正文、辅助文字、注释文字应该有明确的层级区分，而不是每个地方都手动调一个看起来差不多的数值。统一的字号层级能让页面节奏更稳定，也让开发更容易建立全局样式。

切图和图标需要单独整理

图标如果散落在页面里，前端需要一个个找出来导出，很容易漏掉或导出不同尺寸的版本。交付前把需要导出的图标和图片单独整理到一个页面或文件夹里，标注好用途和推荐尺寸，能省去大量来回确认的时间。

检查时注意图标是否统一使用了同一套风格，线性图标和面性图标不要混用，描边粗细要一致。如果图标需要适配不同尺寸的容器，最好导出 SVG 格式，这样缩放不会失真。位图资源要确认分辨率是否足够，特别是用于高密度屏幕的图片。

另外要留意图标是否直接用了不可编辑的格式，或者颜色是否写死。如果图标颜色需要跟随主题变化，应该使用可修改颜色的格式，而不是导出成固定颜色的图片。

容易忽略但影响接手效率的细节

组件和页面的命名如果随意，比如“矩形 12”“副本 3”，过段时间自己都找不到对应位置，更不用说前端或同事接手。命名最好能描述组件的功能和状态，比如“按钮-主要-悬停”“输入框-错误-带提示”，这样文件结构本身就承担了部分文档职责。

设计稿里如果有交互说明，比如页面跳转逻辑、弹窗触发方式、表单校验规则，最好直接标注在对应位置，而不是放在单独的文档里。前端在看设计稿时就能同时获取交互信息，不需要在多个文件之间切换。

还有一个容易被忽略的问题是设计稿的版本管理。如果页面经过多轮修改，交付前要确认发出去的是最新版本，并且把修改过的部分明确标出来。前端如果拿到旧版设计稿开始开发，后面发现对不上，返工成本很高。

交付前最后过一遍清单

实际操作中，可以按这样的顺序检查：先看组件状态是否覆盖完整，再看长文本和空数据场景是否处理过，然后确认窄屏适配规则，接着检查颜色和字号是否使用统一变量，最后整理切图和图标资源。每检查完一项就标记一下，避免遗漏。

如果设计稿中有交互流程，比如表单提交、弹窗关闭、页面跳转，最好把流程图画出来或者用连线标注清楚。前端需要知道用户操作后会发生什么，而不是只看到静态页面。

交付不是把文件发出去就结束了。如果条件允许，可以和前端一起过一遍设计稿，确认双方对状态、适配和交互的理解一致。这个沟通成本远小于开发完成后发现方向不对再返工的成本。把检查清单保留下来，每次交付前对照执行，形成自己的规范文档，后续处理同类任务会越来越快。