微交互升级前：确认触发、打断与无动画路径
把打断当作常规输入
连续点击、页面离开和系统减少动态效果都不应留下悬空回调。业务结果必须先落稳，动画是否播放只是表达层的选择。
动效升级最容易漏掉的不是主流程，而是用户再次点击、快速返回、切换页面和关闭减少动态效果后的表现。先把这些状态列出来，再调视觉细节，能少很多上线后的补丁。
同一状态只由一个地方驱动
同一元素不要同时被 CSS transition、脚本动画和手势逻辑改transform。状态来源分散时，偶发抖动很难复现。让组件统一接收目标状态，动画只负责从当前值过渡到目标值。
function setPanelOpen(open: boolean) { panel.dataset.state = open ? 'open' : 'closed'; }上线前走真实输入方式
鼠标、触屏和键盘的触发节奏不同，都要走一遍。截图和性能轨迹只保存演示数据；发现问题时记录最小步骤、浏览器版本和预期行为即可。
打断后的界面要回到可解释状态
微交互被打断是常态：用户连点两次、系统弹出权限框、页面退到后台，或者网络结果比动画晚到。此时最重要的不是把动画播完，而是界面能回到一个容易理解的状态。按钮应当显示当前是否可继续操作，提交成功或失败要有独立反馈，不要让旋转图标悄悄停住却没有结果。
实现上可以把动画状态和业务状态分开。业务成功后再决定是否播放完成效果；页面销毁时取消控制器和定时器；重新进入时从明确的初始状态恢复。这样即使动画因为性能或无动画设置被跳过，用户仍能看到正确内容。把动画当作状态的表达，而不是状态本身，处理异常会省很多力气。
验收时我会故意在不同节点离开页面、切换网络、开启系统的减少动态效果选项。还要检查读屏用户是否能获得同样的结果提示。微交互的价值在于缩短理解时间，不在于让每一次点击都显得热闹。只要关键反馈没有丢，静态版本也应当是完整的体验。
面板刚打开就被关闭时，用户不关心中间帧是否完整，但会在意焦点、滚动位置和可点击区域有没有恢复。实现里可以让目标状态优先于正在执行的动画：收到关闭指令后，取消旧的过渡并把状态落到 closed，而不是排队等上一段动画结束。这样连续点击不会积累回调。
无动画路径也不能只把时长设成零。有些组件依赖 transitionend 清理状态，时长为零时事件可能不按预期触发。减少动态效果时，应直接调用结束后的状态更新，并确认屏幕阅读器能得到必要提示。把这条路径当成正式功能测试，往往能顺带发现主路径里不必要的时序依赖。
排查问题时，把用户当时看到的状态和业务请求状态分开记录。动画停在半途未必说明请求失败，反过来也一样。两条信息放在同一个诊断页面，才能避免开发只修了表现，实际操作仍然没有完成。
反馈要说明动作是否已经生效
微交互最怕把“正在处理”误画成“已经完成”。例如按钮已被点击但请求仍在等待，就应保留可理解的等待状态，失败后给出再次操作的入口。文案不必很长，只要能区分提交中、成功和失败。动画只是辅助，不应替代这些基础信息。
