will-change: transform 在低端安卓机（Android 5–7、Chrome 60–79）上反而导致卡顿、掉帧甚至白屏，因其强制建层、占内存、锁 z-index、破坏 sticky 和 z-index 排序；应改用 translateZ(0)、contain、touch-action 等更稳方案，并动态 JS 控制图层生命周期。
直接加 will-change: transform 在低端安卓机（尤其是 Android 5–7 WebView、Chrome 60–79）上大概率更卡，不是没生效，而是它提前建层、占内存、锁 z-index、触发白屏——这不是配置问题，是浏览器渲染引擎的固有行为。
为什么低端机加 will-change 反而掉帧甚至白屏
低端机型 GPU 内存紧张、合成器调度能力弱，will-change 的“提示”在它们身上几乎等于强制指令：
-
will-change: transform会立即分配独立图层 + 预上传纹理，一屏 10 个列表项 = 至少 10 个常驻图层，中低端安卓机图层超 5～8 个就开始阻塞纹理上传，帧率断崖式下跌 - Chrome 60–79 中该属性会无条件创建新层叠上下文，子元素
z-index失效，按钮被遮挡、弹窗出不来，DevTools Layout 面板里显示 “Stacking Context: Yes” 就是铁证 - iOS Safari（15.4 及更早）下，只要
position: sticky的任意祖先设了will-change: transform，sticky 查找路径就被截断，直接退化为static - Android 4.3 及以下 WebView 完全不支持 Z 轴排序，
translate3d(0,0,0)和will-change并存时，后渲染的 DOM 元素无条件覆盖前面的，z-index彻底失效
移动端 shouldComponentUpdate 式的动态控制策略
不能靠 CSS 静态声明，必须用 JS 模拟“按需提层 + 精确回收”，类似 React 的更新判断逻辑：
- 只在用户真实交互瞬间设置：
touchstart或mouseenter后、动画 class 应用前那一帧，调用el.classList.add('is-animating') - 移除时机必须双保险：监听
animationend（不是transitionend）同步清除；再加setTimeout(() => el.classList.remove('is-animating'), duration + 100)兜底，iOS Safari 对 ≤16ms 动画常不触发事件 - 避免对
overflow: hidden容器内的元素设will-change，它会抑制图层提升，Layer borders 里看不到橙色边框就是被拦住了 - 若用 JS 驱动（如
requestAnimationFrame手动更新transform），第一帧设will-change，最后一帧清空，中间帧别碰
比 will-change 更稳的降级方案
在低端机上，will-change 是高风险操作；优先用兼容性更好、副作用更小的替代手段：
立即学习“前端免费学习笔记（深入）”；
- 用
transform: translateZ(0)或transform: translate3d(0, 0, 0)显式提层，不依赖浏览器解析逻辑，也不触发额外层叠上下文 - 对可滚动区域加
touch-action: pan-y（纵向）或pan-x（横向），跳过浏览器默认的 300ms 双击判定，让 touchmove 立即响应，比任何图层优化都直接 - 给滑动容器加
contain: layout paint，限制重绘范围，实测在低端安卓上比单加will-change帧率更稳 - 检测低版本环境：
navigator.userAgent.match(/Android\s[2-4]\.[0-3]/)或/Chrome\/[6-7][0-9]/，匹配到就跳过will-change，只用translateZ(0)+contain
真正关键的不是“要不要加”，而是“谁在动、动多久、动完是否立刻收手”。Layer borders 是唯一验证标准——没看到橙色边框，说明所有 will-change 都白写了；看到边框但卡顿，说明图层建多了或没及时回收。低端机上，少建一层，往往比多加一行 CSS 更管用。
