微动效性能瓶颈主要源于DOM操作、布局触发和资源加载耦合——应只对transform/opacity动画，避免重排属性，批量读写DOM，用requestAnimationFrame和pointerdown优化交互，慎用preload/prefetch，优先内联小SVG。
微动效本身不拖慢页面，但写法不当会让它变成性能黑洞——尤其是高频触发、未节流、强制同步布局的操作，会直接卡住主线程。
为什么
CSS :hover 本身很轻量，但一旦动画里包含 width、height、top、left 或 font-size 这类触发重排（reflow）的属性，浏览器就得反复计算布局，尤其在滚动或连续悬停时极易掉帧。
- 只对
transform和opacity做动画，它们走合成层（compositor），不触发布局和绘制 - 避免在
@keyframes里写margin或padding—— 即使是小数值变化也会引发重排 - 用
will-change: transform提前告诉浏览器“这个元素要动”，但别滥用：只加在真正需要动画的元素上，且动画结束后建议移除 - 检查 DevTools 的 Rendering 面板，开启 “Paint flashing” 和 “Layout Shift Regions”，能直观看到哪些操作在强制重排
JavaScript 触发动效时 DOM 操作太重
比如用户点击按钮后，用 element.style.left = x + 'px' 改位置，或频繁读取 offsetTop / getBoundingClientRect()，都会让浏览器在每一帧里反复 layout → paint → composite，形成“布局抖动”（layout thrashing）。
- 把读取和写入操作分开：先批量读完所有需要的尺寸，再批量写样式，避免“读-写-读-写”交叉
- 用
requestAnimationFrame()替代setTimeout或setInterval驱动动画，确保与屏幕刷新率对齐 - 对需实时响应的交互（如拖拽、鼠标跟随），用
IntersectionObserver或ResizeObserver替代scroll/resize事件监听，减少触发频次 - 避免在动效中调用
innerHTML或大量appendChild；改用DocumentFragment批量插入，或用display: none切换显隐代替 DOM 销毁重建
preload / prefetch 对微动效资源没用反而添乱
<link rel="preload"> 是为关键渲染路径服务的，而微动效用到的图标、SVG、小动画 JSON（如 Lottie）通常不属于首屏必需资源。提前拉它们，只会挤占带宽、增加内存压力，甚至触发不必要的解码。
立即学习“前端免费学习笔记（深入）”；
- 只对首次点击就立刻播放的动效资源（如模态框入场动画的 Lottie JSON）考虑
preload，且必须配as="fetch" - 对用户操作后才出现的动效（如悬停展开菜单、长按弹出浮层），用
import()动态加载对应模块，或用fetch()按需拉取资源 - 慎用
<link rel="prefetch">：它会在浏览器空闲时加载，但微动效资源往往有明确触发条件，prefetch 容易白下、缓存浪费 - SVG 内联比外链更稳——没有请求延迟，也不受 preload 控制逻辑干扰；但注意内联体积，单个 SVG 不宜超过 4KB
移动端 touchstart 后的 300ms 延迟破坏动效连贯性
这不是 bug，是浏览器为双击缩放保留的兼容机制。但它会让按钮按下反馈延迟半拍，用户明显感知“不跟手”。
- 加
<meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=no">是基础，但还不够 - 用
touch-action: manipulation告诉浏览器“这个区域只做点击/滑动”，可直接禁用双击缩放，消除延迟 - 对纯点击区域（如按钮、图标），优先用
pointerdown事件替代touchstart，它在 iOS 和 Android 上都无延迟，且兼容鼠标 - 避免在
touchstart里执行复杂 JS 计算或 DOM 修改——延迟本身不可控，再叠加 JS 执行，动效起始帧必然丢
真正容易被忽略的是：微动效的性能瓶颈很少来自动画本身，而来自它和 DOM 更新、事件调度、资源加载之间的耦合方式。删掉一个 offsetHeight 读取，可能比换掉整个动画库更有效。
