加了will-change: transform反而更卡，是因为浏览器会立即为其创建独立合成层、预分配gpu内存并上传纹理，若元素未真实动画或仅短暂动画，资源被白占；中低端安卓机图层超5～8个即阻塞纹理上传，帧率骤降，ios safari更敏感易白屏；常见错误是全局css声明（如.item{will-change:transform;}）导致一屏20项即20常驻图层，且will-change仅为提示非指令，浏览器建层与回收不可控。
will-change 不是帧率开关，加了不等于变流畅；它只对 transform 和 opacity 有效，且必须在动画触发前一刻设置、结束后立刻清除。
为什么加了 will-change: transform 动画反而更卡
浏览器看到 will-change: transform，会立刻为该元素创建独立合成图层、预分配 GPU 内存、上传纹理。但若元素没真动，或只动一次就停，这些资源全白占着——中低端安卓机图层数超 5～8 个后，纹理上传开始阻塞，帧率从 60fps 掉到 20fps；iOS Safari 更敏感，常驻图层过多可能直接白屏。
- 常见错误：
.item { will-change: transform; }全局写在 CSS 里，一屏 20 个列表项 = 20 个常驻图层 -
will-change是提示，不是指令；浏览器是否建层、何时回收，由实现决定，不可控 -
will-change: scroll-position或will-change: contents几乎无效，后者还会强制子树全升层，极易图层爆炸
只对 transform/opacity 生效，其他属性加了也没用
只有 transform 和 opacity 能走合成线程，不触发布局（Layout）和重绘（Paint）。其他任何属性加了 will-change 都救不回来。
-
left: 100px→ 改用transform: translateX(100px) -
top: 50px→ 改用transform: translateY(50px) -
width: 200px→ 若需缩放，优先用transform: scaleX(2)，注意transform-origin - 透明度变化一律用
opacity，别用rgba()改 alpha（后者仍属颜色重绘）
JS 中动态设置 + 清除的正确时机
必须在用户真实交互瞬间设，动画一结束立刻清。不是页面加载时就加，也不是 hover 就加，而是 touchstart 或 mouseenter 触发后、动画 class 应用前那一帧。
- 推荐用 class 控制：
.card.is-animating { will-change: transform; } - 添加时机：
element.addEventListener('touchstart', () => element.classList.add('is-animating')) - 移除须监听
animationend（不是transitionend），并同步清空：element.addEventListener('animationend', () => element.classList.remove('is-animating')) - 若用 JS 动画（
requestAnimationFrame），第一帧设will-change，最后一帧清空
验证是否真加速：不能只看代码，得看 Layers 面板
写了 will-change、用了 transform，不代表真加速。必须打开 Chrome DevTools → Layers 面板，确认目标元素周围出现绿色边框（表示已升层），同时检查有没有意外的图层爆炸（比如父容器也被带升）。
- 若没绿色边框，说明浏览器没响应
will-change提示，可能是元素被overflow: hidden+border-radius组合强制回退软件渲染 - 若初始状态是
display: none或visibility: hidden，will-change根本不生效 - 真正容易被忽略的是：
will-change不是渲染加速器，它是图层资源的预约指令——预约早了浪费，预约错了失效，预约多了拖垮整页
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
