will-change 不是性能开关，仅对 js 或 css transform/opacity 动画有效，须动态设置并立即清除；原生滚动容器、列表项、错设父容器、隐藏元素及带 border-radius+overflow:hidden 的容器均不应添加，否则引发图层爆炸或失效。
will-change 不是性能开关，加了原生滚动容器反而更卡；它只对 JS 或 CSS transform/opacity 驱动的动画起效，且必须动态设置、立刻清除。
哪些元素不该加 will-change: transform
原生可滚动容器（如 overflow-y: auto 的 .scroll-container）加了 will-change: transform 会干扰浏览器内置合成优化，直接导致掉帧。Chrome DevTools Layers 面板里若看到图层数长期 > 8，基本就是滥用信号引发 GPU 图层爆炸。
-
.list-item、.card这类列表项不能静态加will-change: transform—— 一屏 20 个，等于常驻 20 个图层，中低端安卓机纹理上传阻塞，帧率跌破 20fps - 父容器（如
.list-wrapper）设了will-change，但实际位移的是子元素（如.list-content），信号发错对象，图层建得过大、空转耗资源 - 初始为
display: none或visibility: hidden的元素，will-change根本不生效 - 带
border-radius+overflow: hidden的容器会强制回退软件渲染，will-change彻底失效
什么时候该加、怎么加才有效
只有元素在交互过程中真实、高频地执行 transform 或 opacity 变化时，will-change 才可能起作用。必须用 JS 精确控制“预约”和“释放”两个时刻。
- 在
touchstart或mouseenter后、动画 class 应用前那一帧设：element.style.willChange = 'transform' - 动画结束必须监听
animationend（不是transitionend），并设回'auto'：element.style.willChange = 'auto' - 推荐嵌套两层
requestAnimationFrame清除，确保绘制完成后再销毁图层，避免闪屏 - 若用 JS 手动驱动
touchmove更新element.style.transform，且 Performance 面板确认首帧 > 16ms、Layers 面板无橙色边框，才值得加
比 will-change 更稳的替代方案
绝大多数场景下，transform: translateZ(0) 或 transform: translate3d(0, 0, 0) 比 will-change 更可靠：兼容性好、无需 JS 生命周期管理、不会因误设而拖垮整页。
- 侧滑菜单优先写基础类：
.sidebar { transform: translateX(-100%); transition: transform 0.3s ease; }，而非只挂开启动态类 - 配合
contain: layout paint限制重绘范围，效果比单靠will-change更直接 - 对可滚动区域必须加
touch-action: pan-y（纵向）或pan-x（横向），否则浏览器默认手势延迟判定会拖慢响应 - 禁用
scroll-behavior: smooth，它与手动transform滚动叠加会导致视觉撕裂
验证是否真加速：Layer borders 是唯一标准
写了 will-change 或 translateZ(0) 不代表生效。必须打开 Chrome DevTools → Cmd+Shift+P 输入 “Rendering” → 勾选 Layer borders。动画过程中看到橙色边框包裹目标元素，才算真正升层。
- 没边框？检查父级是否设了
overflow: hidden或contain: paint，它们会抑制提层 - 边框闪烁剧烈或图层数暴涨？说明生命周期没闭环，或加给了不该加的元素
- 边框稳定出现但依然卡顿？问题不在渲染层，大概率是主线程被 JS 阻塞、或 scroll 回调里读取了
getBoundingClientRect()这类强制 layout 的 API
最容易被忽略的是：will-change 不是渲染加速器，它是图层资源的预约指令——预约早了浪费，预约错了失效，预约多了拖垮整页。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
