EDITORIAL LIST / 清单文章
微交互 Top 10：10 大经典界面反馈设计
10 条 · 席位已收满
这一版收录的是微交互与反馈里彼此不同的反馈机制。它们经常被笼统地叫作“加载中”或“提示”，但回答的其实是不同的问题：现在在发生什么、进行到哪里、刚才那一下有没有生效。
选择标准
- 描述一次可辨认的反馈，而不是整段流程。
- 与相邻的反馈机制区别清楚：区别在于它能表达什么信息，而不是它长什么样。
- 可以在没有该机制时说出用户会失去什么。
本版席位
标注“编辑重建席位”的位置由本仓库编辑判断补上；其余席位来自计划 issue #1 的清单账本。
骨架屏
内容加载完成前，用与预期内容结构相近的占位形状表示正在加载。
为什么在这一版里：给这一类立一个基准：在结构已知但内容未到时告诉用户内容正在来。
别和它混淆：占位形状不提供完成百分比，也不能把未获取的数据伪装成真实内容。
确定进度条
在已知总量和完成量时，用进度条表示实际完成比例。
为什么在这一版里：补上“能说出完成了多少”的那一类反馈，前提是总量可知。
别和它混淆：百分比必须对应已完成工作；本演示使用手动推进的模拟任务，不代表真实网络速度。
不确定进度指示
当剩余时间或已完成比例无法得知时，用持续旋转的图标或循环滚动的进度条表示系统仍在处理，而不报告具体完成了多少。
为什么在这一版里：补上总量不可知时的表达方式，明确它不能伪装成百分比。
别和它混淆：不确定进度指示只回答“系统还在工作吗”，不量化完成比例或剩余时间；一旦拿到可靠的已完成量和总量，就应换成确定进度条，二者不能互相替代，也不能用旋转图标掩盖本可量化的进度。骨架屏用于内容结构已知、只是在等待该结构被填充的场合；不确定进度指示则用于完成比例本身不可知，或等待发生在整个界面而非某块已知结构上的场合。
行内校验反馈
在用户填写表单的过程中或刚完成某个字段之后，紧贴该输入框显示该字段的校验结果：指出错误、用文字描述问题，并在可能时给出修正建议；对复杂字段也可显示成功确认。
为什么在这一版里：把“校验结果”与“正在编辑”分开：校验不是编辑。
别和它混淆：行内校验只反馈单个字段的输入是否合规，不是就地修改内容的行内编辑，也不是整个错误预防原则（它只是该原则在表单字段层面的一种实现）。时机是关键：多数字段应在用户离开字段或输入长度达到预期后再校验，而不是从第一次击键就报错；密码强度等实时约束例外。提交后的汇总错误列表与状态消息是它的邻居，不能替代紧贴字段的提示。
焦点指示
当界面元素获得键盘焦点时，用可见的视觉标记（如轮廓环或高亮）指出当前焦点所在，使键盘用户始终知道操作会落在哪里。
为什么在这一版里：补上键盘用户判断“我现在在哪里”的可见标记。
别和它混淆：焦点指示只回答“焦点现在在哪”，不等同于悬停、选中或激活状态；它是元素的一种状态样式，而不是一个独立组件，也不负责决定焦点应移到哪里。
按下状态反馈
当用户正在按下或点击一个可操作控件（指针按下到松开之间，CSS 中对应 :active）时，控件立刻呈现可见的视觉变化（可辅以触觉或声音），确认这次按压已被系统接收；动作本身在松开时才完成。
为什么在这一版里：补上“这一下按到了”的即时确认，时间尺度比其他反馈都短。
别和它混淆：按下状态只回答“系统收到我的按压了吗”，发生在按下与松开之间的短暂窗口。它不同于悬停（指针停留但未按下）、焦点指示（键盘焦点在哪）和选中/切换态（松开后仍保留的持久状态），也不承担展示操作结果的职责——结果由状态消息或内容变化来表达。
状态消息
在不改变用户上下文的前提下，简短报告一次操作的结果、等待状态或错误存在的内容变化；它可由辅助技术在不获得焦点的情况下播报。
为什么在这一版里：补上不改变上下文的结果播报，与连续量化的进度分开。
别和它混淆：状态消息只报告结果或状态，不承载连续量化的进度（那是确定进度条），也不阻断当前任务要求回应（那是模态对话框）。Toast 与 Snackbar 是它的呈现变体，不是独立概念。
乐观反馈
在服务器确认之前，界面立即呈现操作预期会成功的结果；请求返回后再与实际结果对齐，若失败则回滚到之前状态并给出清楚的说明与重试路径。
为什么在这一版里：补上“先显示预期结果、再与实际对齐”的做法，并要求失败时能纠正。
别和它混淆：乐观反馈呈现的是尚未确认的预期结果，不同于骨架屏或不确定进度指示——那些承认自己在等待、不冒充结果；也不同于状态消息——状态消息只报告已经发生的真实结果，而乐观反馈是在结果发生之前先行展示。它用对不确定性的诚实换取感知速度，因此只适合失败率低、恢复代价小的操作。
触觉反馈
触觉反馈通过设备振动或力反馈等物理触感，在一次按压、状态变化或事件发生时提供简短的物理确认信号；在 Web 上主要由 Vibration API（navigator.vibrate()）提供，仅在设备存在振动硬件、未处于静音或免打扰模式、且用户已与页面产生交互时才会起作用，规范本身将其定位为面向简单触感反馈的机制，而非通用通知渠道。
为什么在这一版里：补上视觉之外的感知通道，说明反馈不必都是看的。
别和它混淆：触觉反馈是叠加在其他反馈之上的一条辅助通道，用来在指尖上确认一次按压、状态变化或事件；它不能替代按下状态反馈的视觉呈现（那是基础且必需的反馈），也不能替代状态消息对结果的文字或图形说明。这是因为很多用户的设备不具备振动硬件、系统层面已关闭触觉、设备处于静音或免打扰模式，或设备根本没有被握持而感觉不到振动；Web 平台对振动能力的支持也有限且不一致，部分浏览器从未实现，部分已经移除实现。触觉反馈必须始终与至少一种视觉或文本反馈并存，不能单独承担传达事件或状态的责任。
状态过渡动画
当界面元素从一种状态变为另一种状态（例如一个列表行展开为详情面板、一张卡片移动到新的位置）时，用位置、形态或透明度的连续变化展示起点与终点之间的关系，帮助用户理解“这个东西去哪儿了、变成了什么”；触发该动画的用户可以关闭它，且该动画须遵从系统级的减少动态偏好。
为什么在这一版里：补上状态之间的连续性表达，并把减弱动效作为适配变体而非独立词条。
别和它混淆：状态过渡动画只负责解释一次已经发生或即将完成的状态变化从何而来、去往何处，动画本身是解释性的，不是装饰。它不同于不确定进度指示——后者循环播放、不对应任何终点，用来报告工作仍在进行；也不同于按下状态反馈——后者只在按下与松开之间的瞬间确认输入被接收，与状态是否改变无关。“减少动态”不是一个独立词条，而是本词条的适配变体：无论动画本身多么精心设计，都必须能被交互触发方关闭，也必须服从 prefers-reduced-motion 等系统级偏好；关闭动画后，起点与终点状态仍须可读。
与另一版本的关系
与《微交互与反馈 · 2026 关注》相比，这一版不假设内容由模型生成；重合的条目说明这类反馈在新场景下被重新讨论。
证据范围
入选理由说明它补上了哪一种反馈能力，不比较效果好坏。可访问性规范对其中若干条给出可检验的要求，具体见词条来源。