减弱动效：保留结果，减少位移

很多团队把减弱动效理解成把所有 transition 设为零。这样虽然减少了移动，却常常顺带拿走了界面的解释能力：用户点击保存后，不再知道请求是否已经收到；切换工作区后，焦点突然换了位置；删除一项后，列表少了一行，却没有告诉人发生了什么。减弱动效真正要保护的是信息，而不是某一段 CSS 的时长。先写下每个动作需要传递的答案：是谁触发的、系统正在处理什么、结果落在哪里、接下来还能做什么。

把这份答案转成状态表，会比从动画属性开始更可靠。以文件上传为例，默认路径可以有进度填充、短暂旋转和新文件行的进入；低动态路径仍要有“上传中”“已完成”、文件名、可用状态和失败后的重试入口。用户得到的是同一份结果，只是路径不再依赖大范围位移。状态文字、颜色、边框、图标、焦点和层级都能承担信号，其中至少两个应在每个关键状态同时出现，避免只依赖一种感官线索。

审查页面时，把动作按感知负担分成四类：跨屏或跨容器的位移、尺寸快速变化、持续循环、由滚动或手势驱动的跟随。第一类最容易造成空间失衡，适合缩短距离、改为原位淡化或用稳定边界标出变化；第二类可以保留极小的缩放，但应避免从很小尺寸突然放大；第三类常可停在一个可读的静态状态；第四类要保留用户手势和内容位置，让控制感一直在用户手里。分类让方案具有一致性，页面也更容易维护。

替代方案需要匹配原动作的职责。一个抽屉原先从右侧滑入，是为了说明它来自哪里并暂时覆盖主内容；低动态版本可以直接显示抽屉、保持触发按钮的 pressed 状态，并把键盘焦点移到抽屉标题。一个成功 toast 原先从底部升起，是为了让结果被看见；低动态版本可在触发按钮附近更新“已保存”，再在状态区保留一条静态确认。这样做不会让低动态界面变得沉默，它只是把解释从移动转移到更稳定的视觉和语义线索上。

`prefers-reduced-motion` 应该在组件层定义，而不是等到页面末尾再用一条全局覆盖规则收尾。组件契约要说明默认状态、低动态状态、两条路径共同保留的文案和 aria 状态，以及用户在运行时修改系统偏好时如何更新。对可重复使用的 Pack，这份契约还应明确哪些值允许主题或产品覆盖，例如入口距离、是否显示装饰性旋转、成功状态停留多久。把规则放在数据与组件附近，才能避免新页面悄悄回到只会移动的旧习惯。

实现时优先使用同一个状态源。按钮从“保存”变为“保存中”再变为“已保存”，默认版本可以在状态变化周围加入 transform 和 opacity；低动态版本沿用相同的 `data-state`、相同的文字和相同的可访问性通知，只替换视觉过渡。这样测试覆盖的是一个业务流程，而不是两套互不相干的组件。也要尊重手动设置：如果产品提供“减少动效”开关，它的优先级、存储方式和与系统偏好的关系应被写清楚，避免用户每次访问都要重新选择。

低动态模式常常暴露出默认路径里被动画掩盖的问题。弹窗出现得更直接时，焦点是否已经进入弹窗？列表不再滑动时，新增项是否仍然在阅读位置附近？筛选结果立刻替换时，屏幕阅读器能否知道结果数量发生了变化？这些问题决定交互是否完整。每当移除一段视觉运动，都要补查焦点管理、滚动位置、状态区域和键盘返回路径。减弱动效能够成为一面镜子，帮助团队发现原先依赖视觉缓冲掩盖的断点。

同样的原则适用于触摸和拖拽。减少动效并不意味着禁用直接操控；用户拖动滑块、排序任务或拖拽时间线时，内容仍应跟随手势，只是惯性、回弹和装饰性残影可以更克制。要确保松手后的结果在同一位置被确认，并让撤销或恢复入口稳定可见。对于自动播放的轮播、背景浮动和闪烁加载骨架，默认关闭或改为手动触发通常更合适，因为这些动作没有用户输入作为锚点。

验收不应只在浏览器开发工具里勾选一次偏好。把系统偏好切换、产品内开关、键盘操作、触屏操作和窄屏布局放在同一张测试清单中。测试者需要能够回答：我是否看得出提交已经开始？我是否知道失败发生在哪里？我是否还能撤销？我是否能在没有连续运动的情况下理解列表、工作区和层级变化？把回答记录下来，下一次同类组件就能直接复用。

最后再衡量节奏。减弱动效不等于所有东西同时瞬移：一组信息仍可按语义顺序出现，状态仍可在极短时间内交接，焦点仍可被引导。关键是任何时间差都服务于阅读顺序，而不是制造戏剧性。把装饰性时间归零或降到极短，把任务完成、错误定位和内容更新的时间保留在可感知范围。这样无论用户选择哪条路径，产品都保持同一套逻辑和同一份尊重。