will-change在低版本Chrome（60–79）中强制创建不可控层叠上下文，使子元素z-index仅在内部生效，导致与外部同级元素层叠失效；需动态JS控制、用translateZ(0)替代并验证图层生成。
低版本浏览器里 will-change 导致层级错乱，不是“加得不够”，而是它在旧引擎里创建了层叠上下文却没配好 Z 轴排序逻辑——结果就是 z-index 看似失效，实际是被锁进了一个没出口的小房间。
Chrome 60–79 中 will-change 触发的层叠上下文不可控
老 Chrome（尤其是 60–75）对 will-change 的解析很粗糙：它可能只响应 transform 却忽略 opacity，也可能因父容器有 overflow: hidden 或 transform 直接拒升图层。更麻烦的是，一旦升层成功，它就强制创建新层叠上下文，子元素的 z-index 只在内部生效，和外部同级元素完全不比大小。
- 典型表现：
.modal加了will-change: transform，里面按钮设z-index: 9999，仍被没加will-change的导航栏盖住 - DevTools 中右键元素 → «Layout» 标签页 → 显示 “Stacking Context: Yes”，基本可确认被隔离
- 不要指望
will-change: auto能撤回——必须显式设为will-change: initial或删掉该声明
Safari 下 will-change 让 sticky 定位直接退化
在 iOS 15.4 及更早 Safari 中，只要 position: sticky 元素的任意祖先设置了 will-change: transform（哪怕只是父容器），就会触发新的滚动上下文，导致 sticky 查找路径被截断，computed position 直接变成 static。
- 不是闪烁，是定位逻辑被重定向；加
will-change不仅不修复，反而让问题更彻底 - 检查顺序必须是：
position: -webkit-sticky在前，position: sticky在后，否则整条规则被丢弃 - sticky 元素的最近滚动祖先必须同时满足：
overflow-y: auto（不能是scroll） + 显式height或max-height
Android 4.3 及以下 WebView 中 translate3d 和 will-change 双重失效
旧安卓 WebView（2.x–4.3）根本不支持 3D 图层的 Z 排序，translate3d(0,0,0) 或 will-change: transform 都会强制创建独立图层，但渲染时按 DOM 顺序硬画，后出现的元素无条件覆盖前面的——z-index 彻底失效。
立即学习“前端免费学习笔记（深入）”；
- 别用
translate3d做“硬件加速开关”，它在这里只是把绘制甩给 GPU，却不提供深度缓冲 - 检测方式：
navigator.userAgent.match(/Android\s[2-4]\.[0-3]/)，匹配到就降级为纯 CSS 动画或transform: translate()+will-change: transform（需实测） - iOS 上类似问题源于
transform-style: preserve-3d的激进实现，修复要靠父容器设该属性 + 子元素显式translateZ()
真正有效的替代方案：动态 + 可控 + 验证
静态写死 will-change 在低版本里几乎等于主动制造 bug。可靠做法是只对真实发生 transform 或 opacity 变化的元素，在动画帧开始前 1–2 帧用 JS 设置，结束立刻清空。
- 优先用
transform: translateZ(0)替代will-change: transform——兼容性更好，升层更轻量，且不触发额外层叠上下文 - 避免混用：
will-change: transform, opacity但动画只变其中一个，多余提示会增加准备成本 - 验证是否真起作用：打开 Chrome DevTools → «Rendering» → 勾选 «Layer borders»，看到目标元素带绿色边框才算升层成功；若满屏闪绿，说明泛滥了
最常被忽略的一点：will-change 是高代价预分配指令，不是性能开关。它本身不节省 CPU 时间，反而吃 GPU 内存——只有当你已确认该元素确实是瓶颈，且变化属性确为 transform 或 opacity 时，才值得引入并精细控制生命周期。
