UI 动画与动效设计

要解决什么问题

界面动效常常是"事后补"的：功能写完后随手加一个 transition，时长随手填 300ms，缓动函数一律 ease-in-out。结果要么动效拖沓挡住操作，要么低端机上掉帧，要么无视 prefers-reduced-motion 让前庭敏感的用户眩晕。这个技能要解决的问题，是把动效从"装饰"变成一套有依据、有约束、可验收的工程实践。

它如何工作

技能按"原则 → 时长 → 缓动 → 模式 → 性能 → 选型 → 无障碍"的顺序组织：

• 动画原则：把经典 12 原则映射到 UI 场景，比如 Timing 的时长反映重要性与距离、Staging 引导视线到关键元素、Squash & Stretch 用于有弹性的趣味交互。
• 时长与缓动：按距离决定时长；用 ease-out 入场、ease-in 出场、ease-in-out 做屏幕内状态变化，bounce/spring 只留给需要引人注意的场景。
• 动效模式：覆盖微交互、加载态、页面转场、列表动画四类常见场景。
• 性能：只动 transform 和 opacity 这类 GPU 加速属性，配合 FLIP 技术处理复杂位移。
• 库选型：给出对比表——CSS / Web Animations API 零体积适合简单过渡，GSAP 适合复杂精确控制（~60kb），Framer Motion 面向 React（~50kb），anime.js 擅长时间轴与 SVG（~17kb），Motion One 轻量现代（~18kb），Lottie 承接 After Effects 导出（~50kb）。
• 平台差异：iOS 用弹簧物理 300–500ms，Android 走 Material motion 200–300ms，Web 通常 200–400ms。

适用边界

这是一份设计/工程参考，不是代码生成器——它不直接产出可运行的动画，而是给出决策依据和验收清单（事前检查目的性、实现时检查 GPU 加速与 reduced-motion、上线前检查自然度与一致性）。动效必须服务于反馈与引导，纯装饰性动画、阻挡交互、过度回弹都属于明确禁止的反模式。