will-change 不会让 z-index “失效”，而是创建新层叠上下文，使子元素 z-index 仅在内部生效；will-change: transform/opacity/scroll-position 会触发，而 left/width 不会；可用 Chrome DevTools 的 Layer borders 和 Rendering 面板验证。
will-change 不会让 z-index “失效”，而是悄悄创建了一个新层叠上下文，把子元素锁进自己的 Z 轴小房间——外面的 z-index 再大也敲不开门。
为什么加了 will-change: transform 后按钮被导航栏盖住
典型表现是：弹窗容器设了 will-change: transform，里面按钮写了 z-index: 9999，仍被没加该声明的导航栏压住。这不是数值不够，而是浏览器为该容器强制创建了层叠上下文，子元素的 z-index 只在它内部生效，和外部同级元素完全不比大小。
触发条件很明确：will-change: transform、will-change: opacity、will-change: scroll-position 都会建新上下文；而 will-change: left、will-change: width 等不会。
- Chrome DevTools 中右键元素 → «Layout» 标签页 → 显示 “Stacking Context: Yes”，基本可确认被隔离
-
will-change: auto无效；will-change: unset不清除已有上下文，必须用will-change: initial或直接删掉该声明 - 不要指望靠提升父容器的
z-index来“带飞”子元素——那只会把它锁死在更小的房间里
如何验证是否真被 will-change 隔离了
别靠猜，用 Chrome DevTools 实锤：
立即学习“前端免费学习笔记（深入）”；
- 打开 Rendering 面板 → 勾选 «Layer borders»：看到绿色边框矩形，就是独立图层已激活
- Elements 面板右键可疑元素 → «Inspect rendering layers»：直接跳转到 Layers 面板看层级树
- 关键信号：
getComputedStyle(el).zIndex返回"auto"，但视觉上却盖住了兄弟元素 → 说明它靠的是层叠上下文优先级，不是z-index值 - 临时给父容器加
outline: 2px solid red，确认你操作的确实是“层叠上下文根”，而不是你以为的“子元素”
替代方案：要性能，又不想乱建上下文
多数场景下，will-change 是过早优化。先试试更轻量、副作用更可控的写法：
- 动画前用 JS 动态设置：
el.style.willChange = 'transform'，动画结束立刻设回'auto'（监听transitionend） - 用
transform: translateZ(0)替代 —— 它强制升层但不额外建上下文（注意：别滥用在列表项上，否则图层数爆炸） - 若目标元素需跨容器竞争层级（如弹窗、Tooltip），把它提到同一层叠上下文根节点下，比如挂到
body下，而非嵌套在那个带will-change的容器里 - 对 Safari iOS 15.4 及更早版本，
will-change: transform会让position: sticky直接退化成static，此时必须删掉或降级为纯 CSS 动画
Android 4.3 及以下 WebView 的特殊处理
旧安卓 WebView（2.x–4.3）根本不支持 3D 图层的 Z 排序，translate3d(0,0,0) 或 will-change: transform 都会强制创建独立图层，但渲染时按 DOM 顺序硬画，后出现的元素无条件覆盖前面的——z-index 彻底失效。
- 检测方式：
navigator.userAgent.match(/Android\s[2-4]\.[0-3]/)，匹配到就降级 - 可用
transform: translate()+will-change: transform组合（需实测），或直接弃用硬件加速，改用纯 CSS 动画 - 别用
translate3d做“硬件加速开关”，它在这里只是把绘制甩给 GPU，却不提供深度缓冲
真正麻烦的不是 will-change 本身，而是它常和 transform、opacity、filter 在不同嵌套层级叠加——多重层叠上下文嵌套后，z-index 就像被关进好几层保险柜，钥匙还丢了。动手前先用 Layers 面板扫一眼，比硬调数值快十倍。
