应通过媒体查询控制元素的animation属性而非@keyframes；移动端用ease-out、时长≤0.35s，桌面端可用复杂缓动及时长0.5s；优先用prefers-reduced-motion禁用动画，老旧安卓可结合JS检测加no-animation类；transition适合状态切换，animation适合精确时序；will-change需谨慎动态添加，移动端推荐translateZ(0)替代。
怎么用媒体查询区分移动端和桌面端的动画行为
直接在 @keyframes 里写媒体查询是无效的——CSS 动画定义本身不响应断点。真正起作用的是控制 animation 属性是否启用、或切换不同动画名，靠的是对元素本身的媒体查询规则。
常见错误：把 @media (max-width: 768px) 套在 @keyframes slide-in 外面，结果动画完全不触发。
- 只在元素选择器上加媒体查询，比如
@media (max-width: 768px) { .card { animation: mobile-slide 0.3s ease; } } - 桌面端用复杂缓动（
cubic-bezier(0.25, 0.46, 0.45, 0.94)），移动端统一用ease-out，避免卡顿 - 动画时长建议：桌面端可到
0.5s，移动端别超过0.35s，否则手指操作节奏被拖慢
如何禁用低端安卓机的 CSS 动画以保流畅
不是所有“移动端”都适合跑动画。部分 Android 低版本 WebView（如 Android 4.4 的系统浏览器）对 transform + opacity 组合动画支持差，容易掉帧甚至闪屏。
关键判断依据不是 UA，而是 prefers-reduced-motion 和实际硬件能力检测。
立即学习“前端免费学习笔记（深入）”；
- 优先加
@media (prefers-reduced-motion: reduce) { * { animation-duration: 0.01ms !important; animation-iteration-count: 1 !important; } } - 对老旧安卓设备，可在 JS 中检测
matchMedia('(max-width: 480px) and (resolution: 1dppx)').matches配合 UA 判断，然后给加class="no-animation"，再用 CSS 覆盖 - 禁用时别用
animation: none，它会清空整个动画声明；改用animation-duration: 0s更稳妥
transition 和 animation 在响应式切换时谁更可控
transition 更适合状态驱动的简单动效（如 hover、focus、展开收起），animation 更适合需要精确时间轴、多阶段、循环或事件触发的场景（如加载骨架、页面入场）。两者混用容易冲突。
- 如果只是按钮点击后颜色+缩放变化，用
transition: background-color 0.2s, transform 0.2s，再通过 class 切换控制，比写两套@keyframes更轻量 - 但页面路由切换时的入场动效，必须用
animation，因为transition无法监听“从无到有”的插入时机 - 注意：
transition不支持媒体查询内重定义属性值，只能靠 class 切换；而animation可以在不同媒体查询中指定不同animation-name
为什么用 will-change 后动画反而卡顿
will-change 不是性能银弹，滥用会导致内存暴涨、图层爆炸，尤其在频繁进出视口的列表项上。
典型错误：给所有带动画的元素统一加 will-change: transform, opacity，结果 Chrome 内存占用翻倍，滚动变卡。
- 只对明确即将动画、且生命周期可控的元素动态添加，比如
element.style.willChange = 'transform'，动画结束立刻设回'auto' - 移动端慎用，iOS Safari 对
will-change的图层管理更激进，容易引发白屏或渲染错位 - 替代方案：用
transform: translateZ(0)或translate3d(0,0,0)触发硬件加速更稳妥，兼容性也更好
动效策略真正的复杂点不在写法，而在判断“这个动效此刻是否值得运行”——用户手势、设备负载、系统偏好、网络状态，都会影响最终表现。漏掉任意一环，都可能让精心设计的动画变成体验负分项。
