UI设计稿里按钮的悬停、禁用、加载状态，开发说上线前再补，该听吗？

按钮的悬停、禁用、加载状态，不能等到上线前再补。至少要有“默认、按下、禁用、加载中”四态定义；理由不是美观，而是防误操作、给反馈、保可用性。2026年项目交付习惯里，开发通常在组件库或代码里预留状态位，设计稿若缺失，开发就会“自己补”，补出来的偏差往往在验收阶段集中爆发。所以，“上线前再补”的建议，不能全听。

先分清两件事：状态和变体

很多混乱来自把按钮“状态”和“变体”混为一谈。状态是按钮对用户交互的反馈，如默认、悬停、按下、禁用、加载；变体是视觉层级，如主要、次要、危险按钮。两者经常被混淆，导致设计稿铺开几十个样式，真正缺的禁用、加载却没人管。

按常见交付习惯，一个业务界面至少要考虑“主按钮×默认/按下/禁用/加载”这一组矩阵；桌面端再加悬停和聚焦。比如主按钮和次按钮是变体区别，而默认、悬停、禁用是状态区别。判断技巧：如果两个状态差异只是透明度或深浅色，可以合并成一条规则；如果差异来自不同交互场景，就必须单独标注。

状态缺失的代价：别让开发自己补

状态缺失直接导致两种结果：一是用户误操作，点击没有反馈的按钮会反复点，以为系统卡了；二是开发自行补样式，补的往往是“灰色+默认光标”，没有禁用原因，也没有加载说明。

一次项目现场，设计稿只标了“默认”和“按下”两态，开发在写禁用逻辑时自己用了灰色，还把鼠标指针设为默认，结果用户点击无反应还以为系统死机。后来返工加了禁用说明和加载状态，前后改了两轮，多花了大半周。约束条件是项目周期只有三周、没有专职设计走查；做法是先列状态清单再让开发确认。这个返工成本，在常见项目中约占整个设计阶段的10%-20%（经验区间）。

开发自己补的状态，通常不会考虑聚焦态，键盘用户会完全迷失；也不会考虑禁用原因，用户只会得到一个灰色按钮。按钮状态缺失不是“样式不全”，而是交互契约的缺失；开发自己补的状态，补充的是开发的理解，不是设计的意图。

三步核对法：把状态清单定下来

与其凭感觉“能省就省”，不如用三步核对法把状态清单定出来，适合页面较多、交付周期紧的项目。

1. 列类型：把当前页面的按钮分成主要、次要、文字、图标等几类，一般不超过5类。
2. 圈状态：对每种类型，圈出“可点击、不可点击、正在处理中”三个场景，每个场景对应哪些状态。
3. 对清单：把圈出的状态与团队组件库已有状态逐项比对，设计稿缺的补上，组件库已统一的直接写“沿用组件库”。

为什么这样划分？因为“不可点击”和“正在处理”是用户更容易卡住的地方，比“悬停”更容易引发投诉。做到“每个关键按钮都有禁用、加载、按下三个反馈”算合格；如果组件库已有统一默认值，设计稿至少标注“沿用组件库”，不能什么都不写。如果页面里超过1/3的按钮都需要自定义状态，说明设计系统基础还太弱，先补基础颜色和圆角，再谈状态。关键是让开发和设计用同一套词汇，避免“禁用”和“置灰”被当成两件事。

三种方案怎么选：全画、只画核心、交给开发

很多人纠结“要不要全画”，其实是没分清成本。按2026年项目交付习惯，适合中小项目的方式不是“全画”，也不是“不画”，而是“核心态画全，其他态沿用组件库”。

• 方案A：全画全，每种按钮×所有状态都出稿。成本高、周期长，适合大型B端系统或交易链路，能作为视觉回归基线，但对小项目是负担。一个中等模块全画比只画核心态多花半天到一天（经验区间）。
• 方案B：只画核心四态，主次按钮画出默认、按下、禁用、加载，悬停和聚焦由组件库统一。成本可控，比方案A省约1/3标注时间（经验区间）。
• 方案C：不画，开发补，只适合一次性内部原型验证；正式上线时，验收阶段容易出现认知偏差和返工。

对比下来，大多数中小团队适合方案B，但前提是组件库确实存在并覆盖悬停与聚焦；否则“沿用组件库”就是空话。方案C看似快，实际在“开发自查”和“设计走查”两个环节，会以口头沟通和改稿的方式把时间补回来。以上对比基于中小项目经验区间，具体以团队情况为准。

常见坑与合格标准

状态设计有几个常见坑，出现率较高：

• 只置灰没说原因，用户以为功能坏了，甚至反复点击。
• 加载只转圈没文字，超过2~3秒用户想退出。
• 移动端照搬悬停态，触屏根本没有悬停。
• 差异只靠颜色，色弱和读屏器用户无法识别。
• 没有按下态，移动端点按没有物理反馈。

合格标准是状态之间差异清晰，且每种状态写明触发条件和持续时长；比如禁用要说明原因，加载要说明预期等待时间。这样开发不用再问“加载要多长时间”、“禁用要不要提示”。

适用与不适用边界

这套“先列状态清单再取舍”的方式，适合中小型网站、管理系统、移动端APP，以及需要快速交付的迭代项目；对开发团队是否已有组件库没有硬性要求，但如果有，效率会更高。外包项目建议在报价阶段就明确状态清单，避免后期以“设计稿不完整”为由扯皮。

不适合的情况：一次性活动页、纯展示页、没有关键操作的原型验证，确实不必把状态画全；如果整个设计体系还没建立基础样式，先不要追求状态完备，先把默认、按下两态和颜色规范定好。

边界句：如果项目生命周期有限，或操作路径没有关键任务，可以不画全；但涉及支付、删除、保存、提交的关键按钮，状态缺一不可。

常见问题

悬停状态在移动端可以省略吗？

可以。触屏没有悬停概念，移动端只要设计默认、按下、禁用、加载；悬停主要针对桌面浏览器，可按组件库默认处理。

禁用按钮要不要带说明文字？

要。单靠灰色不够，禁用时长或原因应写在附注、提示或按钮旁边的文字里，避免用户以为功能坏了。

加载中状态一般要转多久才合适？

常见经验区间是1.5秒以内用转圈，超过3秒应考虑进度条或分步反馈；但具体按业务和场景设定，没有固定秒数。

开发说组件库里已有这些状态，设计稿还要重复标注吗？

要。至少在备注中写“沿用组件库默认状态”，并给出关键异常态的示例；否则开发无法确认你用的是哪一层样式。

没有专门设计资源时，怎么保证按钮状态一致？

可以先只定义一套核心四态，配好色板和深浅色，再沿用组件库；如果组件库也没有，就优先保证“禁用、加载、按下”三个状态，其他延后。