加 transform: translateY(-2px) 更顺，因其触发硬件加速交由 GPU 处理；而 top 改变布局需重排，易卡顿。
hover 时元素轻微上浮 + 阴影增强，为什么加 transform: translateY(-2px) 比 top: -2px 更顺？
因为 transform 触发硬件加速，浏览器会把它交给 GPU 处理；而 top 改变的是布局位置，每次触发都要重排（reflow），动画一卡一卡的，尤其在低端设备或复杂页面里明显。
实操建议：
- 统一用
transform做位移、缩放、旋转，别混用left/top - 配合
transition: transform 0.2s ease-out, box-shadow 0.2s ease-out，避免只写all——那样连color变化也会被拖进过渡，反而干扰感知 - 加
will-change: transform在 hover 前置声明（但别滥用，只对高频交互元素加）
点击按钮后显示「已提交」状态，用 @keyframes 还是 transition？
用 transition。微动效不是“播放一段动画”，而是状态切换的视觉衔接——比如按钮从 opacity: 1 → opacity: 0.7 + scale: 0.98，靠 transition 就够了；@keyframes 适合需要多阶段、非线性节奏（比如弹跳、呼吸）的场景，反而增加维护成本。
常见错误现象：点了没反应，或状态回退时闪一下
立即学习“前端免费学习笔记（深入）”；
- 确保目标元素有明确的初始状态（比如写死
opacity: 1），别依赖浏览器默认值 - 状态类名切换要同步，比如 JS 中先加
is-submitted，再让 CSS 控制该类下的transform和opacity - 避免在
:active里写复杂动画——移动端 touch 事件和 click 有延迟，容易错位
输入框获得焦点时边框颜色渐变，outline 和 border 哪个更可控？
必须用 border。outline 不参与盒模型，无法设置圆角衔接、不能单独控制某一边、且多数浏览器下不支持 transition（Safari 尤其顽固）。border 虽然要小心处理 box-sizing，但所有行为都可预测。
使用场景：表单校验、搜索框激活态、暗色模式适配
- 始终设
box-sizing: border-box，避免 focus 时宽度突变 - 颜色过渡推荐用 HSL 而非 HEX：
border-color: hsl(210, 80%, 60%)→hsl(210, 100%, 50%)，明度/饱和度调节能保证视觉一致性 - 别忘了
outline: none，否则键盘用户 tab 切换时双轮廓难看又干扰
用 prefers-reduced-motion 关闭动效，但部分用户仍反馈“晃眼”，问题出在哪？
因为只监听了系统级开关，却没覆盖 JS 主动触发的 class 切换（比如轮播图自动滚动、下拉菜单展开）。CSS 媒体查询管不了 JS 行为，必须两端协同。
实操建议：
- CSS 层加
@media (prefers-reduced-motion: reduce) { * { animation-duration: 0.01ms !important; animation-iteration-count: 1 !important; } } - JS 层用
window.matchMedia('(prefers-reduced-motion: reduce)').matches判断，该停轮播就停，该禁用scrollIntoView({ behavior: 'smooth' })就禁用 - 特别注意第三方组件（如日期选择器、Modal），它们常自带动效且不响应媒体查询——得手动 patch 或换配置项
最易被忽略的是：微动效一旦嵌套在组件内部（比如一个按钮组件自带 hover 动画），父级页面即使开了 reduced motion，也得靠组件自身支持才能关闭。别假设“全局关了就万事大吉”。
