will-change 不能解决 z-index 层级混乱，反而常是根源：它会触发新层叠上下文，使子元素 z-index 仅在内部生效，无法与外部同级元素比较层级。
will-change 不能解决 z-index 层级混乱，反而常是根源
直接说结论：will-change 不是用来“修复” z-index 错乱的，它是触发层叠上下文（stacking context）的常见诱因之一。加了 will-change: transform 后按钮被导航栏盖住，不是因为 z-index 写小了，而是浏览器为该元素创建了新层叠上下文——子元素的 z-index 只在它内部生效，和外部同级元素完全不比大小。
典型错误场景：
- 给弹窗容器设
will-change: transform，里面按钮写z-index: 9999，仍被没加该声明的导航栏压住 - 用
will-change: auto或will-change: unset试图撤回上下文——无效，必须用will-change: initial或直接删掉声明 - 以为提升父容器
z-index就能“带飞”子元素——结果只是把整个小房间锁得更死
Chrome DevTools 怎么确认是不是被 will-change 隔离了
别靠猜，用实锤验证：
- 打开 Chrome DevTools → Elements 面板右键可疑元素 → «Inspect rendering layers»：跳转到 Layers 面板看是否独立成层
- Elements 面板右侧 Layout 标签页里看 «Stacking Context» 是否标为 Yes
- 控制台执行
getComputedStyle(el).zIndex返回"auto"，但视觉上却盖住了兄弟元素 → 说明它靠的是层叠上下文优先级，不是z-index值 - 临时加
outline: 2px solid red确认你操作的确实是“层叠上下文根”，而不是你以为的“子元素”
哪些 will-change 值会建新层叠上下文
触发条件很明确，不是所有值都危险：
立即学习“前端免费学习笔记（深入）”；
- 会创建新层叠上下文：
will-change: transform、will-change: opacity、will-change: scroll-position - 不会创建：
will-change: left、will-change: width、will-change: height（这些不触发合成层，也不建上下文） -
will-change: auto是无效值，浏览器忽略；will-change: initial才能真正清除已有上下文
真要性能又不想乱建上下文，试试这些替代方案
多数场景下，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直接退化，此时必须移除，不能靠加别的属性补救
真正麻烦的从来不是 z-index 值写多大，而是你根本没意识到那个加了 will-change: transform 的 div 已经成了“独立王国”——它的子元素再怎么喊 z-index: 999999，也出不了门。
