CSS 微交互动效先表达状态再追求顺滑一、动效不是装饰它应该回答“发生了什么”现代 CSS 已经足够强大过渡、关键帧、容器查询和 View Transitions 都能做出漂亮效果。但在轻量产品里动效的首要任务不是让界面显得高级而是表达状态变化。按钮按下、卡片进入、列表重排、保存成功这些瞬间如果没有反馈用户会不确定反馈过度又会打断任务。微交互要先从状态表开始设计。哪些状态需要动效哪些只需要颜色变化哪些应该完全静默。比如保存中可以用细微进度保存成功只需要短暂反馈保存失败则必须明确停留。不同状态的动效强度不应该一样。二、用状态机约束动效而不是到处写 transition把动效散落在 CSS 类里短期很快长期会混乱。更好的方式是先定义组件状态再让样式消费状态。这样设计、开发和测试都能围绕同一组状态讨论。stateDiagram-v2 [*] -- Idle Idle -- Hover: 指针进入 Hover -- Pressed: 按下 Pressed -- Loading: 提交 Loading -- Success: 成功 Loading -- Error: 失败 Success -- Idle: 反馈结束 Error -- Idle: 用户确认这个状态机还可以帮助设置动效优先级。Hover 是弱反馈Pressed 是即时反馈Loading 是持续状态Error 是阻断状态。每一种都应该有不同的持续时间和视觉权重。三、写 CSS 时给用户偏好和布局稳定留空间动效必须尊重prefers-reduced-motion。这不是可选优化而是基础可访问性。另一个容易忽略的问题是布局稳定。动效不要改变元素真实尺寸优先使用 transform 和 opacity避免重排。.saveButton { inline-size: 96px; block-size: 36px; transition: transform 160ms ease, opacity 160ms ease, background-color 160ms ease; } .saveButton[data-statepressed] { transform: translateY(1px) scale(0.98); } .saveButton[data-stateloading] { opacity: 0.72; pointer-events: none; } .saveButton[data-stateerror] { background-color: #b42318; } media (prefers-reduced-motion: reduce) { .saveButton { transition: none; } .saveButton[data-statepressed] { transform: none; } }这里固定了按钮尺寸避免文案从“保存”变成“保存中”时撑开布局。真实产品里可以用图标和状态文本分离让按钮宽度保持稳定。四、动效的成本要用性能和注意力一起评估CSS 动效看起来轻但不是没有成本。大量阴影、滤镜和模糊会增加绘制压力。列表重排时如果每个卡片都有复杂动画低端设备会明显掉帧。应优先使用 transform并用 DevTools 检查渲染路径。注意力成本同样重要。一个页面如果每个控件都在动用户会失去重点。微交互应该有层级核心任务动效更明确辅助区域更克制背景区域尽量静默。尤其是写作、排版、数据整理类工具界面应该支持长时间工作而不是不断争夺注意力。还要避免用动效掩盖慢接口。加载动画可以缓解等待但不能替代性能优化。超过预期的等待应该显示可取消、重试或离线保存路径。动效是状态语言不是遮羞布。五、总结CSS 微交互动效要从状态出发而不是从效果出发。先定义状态机再用稳定尺寸、可访问性偏好和低成本属性实现反馈。好的动效应该让用户更确定发生了什么同时不打断任务。顺滑只是结果清楚才是目标。
CSS 微交互动效先表达状态再追求顺滑一、动效不是装饰它应该回答“发生了什么”现代 CSS 已经足够强大过渡、关键帧、容器查询和 View Transitions 都能做出漂亮效果。但在轻量产品里动效的首要任务不是让界面显得高级而是表达状态变化。按钮按下、卡片进入、列表重排、保存成功这些瞬间如果没有反馈用户会不确定反馈过度又会打断任务。微交互要先从状态表开始设计。哪些状态需要动效哪些只需要颜色变化哪些应该完全静默。比如保存中可以用细微进度保存成功只需要短暂反馈保存失败则必须明确停留。不同状态的动效强度不应该一样。二、用状态机约束动效而不是到处写 transition把动效散落在 CSS 类里短期很快长期会混乱。更好的方式是先定义组件状态再让样式消费状态。这样设计、开发和测试都能围绕同一组状态讨论。stateDiagram-v2 [*] -- Idle Idle -- Hover: 指针进入 Hover -- Pressed: 按下 Pressed -- Loading: 提交 Loading -- Success: 成功 Loading -- Error: 失败 Success -- Idle: 反馈结束 Error -- Idle: 用户确认这个状态机还可以帮助设置动效优先级。Hover 是弱反馈Pressed 是即时反馈Loading 是持续状态Error 是阻断状态。每一种都应该有不同的持续时间和视觉权重。三、写 CSS 时给用户偏好和布局稳定留空间动效必须尊重prefers-reduced-motion。这不是可选优化而是基础可访问性。另一个容易忽略的问题是布局稳定。动效不要改变元素真实尺寸优先使用 transform 和 opacity避免重排。.saveButton { inline-size: 96px; block-size: 36px; transition: transform 160ms ease, opacity 160ms ease, background-color 160ms ease; } .saveButton[data-statepressed] { transform: translateY(1px) scale(0.98); } .saveButton[data-stateloading] { opacity: 0.72; pointer-events: none; } .saveButton[data-stateerror] { background-color: #b42318; } media (prefers-reduced-motion: reduce) { .saveButton { transition: none; } .saveButton[data-statepressed] { transform: none; } }这里固定了按钮尺寸避免文案从“保存”变成“保存中”时撑开布局。真实产品里可以用图标和状态文本分离让按钮宽度保持稳定。四、动效的成本要用性能和注意力一起评估CSS 动效看起来轻但不是没有成本。大量阴影、滤镜和模糊会增加绘制压力。列表重排时如果每个卡片都有复杂动画低端设备会明显掉帧。应优先使用 transform并用 DevTools 检查渲染路径。注意力成本同样重要。一个页面如果每个控件都在动用户会失去重点。微交互应该有层级核心任务动效更明确辅助区域更克制背景区域尽量静默。尤其是写作、排版、数据整理类工具界面应该支持长时间工作而不是不断争夺注意力。还要避免用动效掩盖慢接口。加载动画可以缓解等待但不能替代性能优化。超过预期的等待应该显示可取消、重试或离线保存路径。动效是状态语言不是遮羞布。五、总结CSS 微交互动效要从状态出发而不是从效果出发。先定义状态机再用稳定尺寸、可访问性偏好和低成本属性实现反馈。好的动效应该让用户更确定发生了什么同时不打断任务。顺滑只是结果清楚才是目标。
