内存暴涨最常见原因是transition: all、滥用will-change、频繁创建未释放的合成层；三者均导致浏览器长期驻留GPU图层，而非动画复杂度本身。
直接说结论：transition: all、滥用 will-change、频繁创建未释放的合成层，这三类情况是内存暴涨最常见原因，不是动画本身复杂，而是浏览器被迫长期驻留 GPU 图层。
为什么 transition: all 会悄悄吃掉内存
它不只让 opacity 或 transform 动起来，还会监听 width、margin、left、background-color 等所有可动画属性——哪怕你只改了 opacity，浏览器仍得为每个属性做插值准备，触发重排/重绘路径，并可能提前升层。Safari 和 Firefox 尤其敏感，transition-property: all 在 :hover 或 .active 类里出现一次，就可能让整块区域常驻合成层。
- 用 DevTools Elements 面板 Ctrl+F 搜
transition: all或transition-property: all，重点检查动态类名 - 运行这段脚本快速定位：
Array.from(document.querySelectorAll('*')).filter(el => getComputedStyle(el).transitionProperty === 'all').forEach(el => console.warn('All transition found:', el)) - 替换原则：只写明确要动的属性，例如
transition: transform 0.2s, opacity 0.2s，绝不加width、top、margin
will-change 写在 CSS 里等于内存定时炸弹
will-change: transform 不是“开启硬件加速”的开关，而是向浏览器发一个“请提前建图层”的请求。静态写死在样式表中，等于让元素永远占着 GPU 纹理内存——iOS Safari 几乎不回收闲置图层，几十个列表项同时挂着，几 MB × N，OOM 崩溃就在滚动两屏后。
- 危险写法：
.item { will-change: transform; }（尤其配合v-for或map） - 正确时机：在
touchstart或mouseenter事件中动态设置el.style.willChange = 'transform' - 必须配对清除：监听
transitionend（加{ once: true }）或animationend，执行el.style.willChange = 'auto'；iOS Safari 可能不触发，需加setTimeout(..., duration + 100)兜底
高频重绘 + transform 混用导致图层堆积不释放
像饼图每毫秒调一次 transform: rotate(...) translate3d(0, 0, 0)，每次渲染都可能生成新图层，但旧 DOM 节点没删，浏览器无法复用纹理——内存曲线会持续爬升，不是卡顿，是真·泄漏。
立即学习“前端免费学习笔记（深入）”；
- 关键动作：动画前先清理旧节点，例如
document.querySelectorAll('.slice').forEach(el => el.remove()) - 避免
position: fixed元素反复刷transform，部分 Android WebView 会丢失锚点并额外创建图层 - 别依赖
translate3d(0, 0, 0)强升层，它和will-change一样，滥用就失控；优先用动态will-change+ 显式销毁
真正难处理的不是“怎么加动画”，而是“怎么干净地收尾”——图层一旦创建，不主动删、不清除、不降级，就会一直躺在 GPU 内存里，直到页面刷新或系统强制回收。
