will-change 会让 z-index 看似失效，根本原因是它强制创建新的层叠上下文，使子元素的 z-index 仅在该上下文中生效，无法与外部同级元素正确层叠。
will-change 为什么会让 z-index 看似失效
根本原因不是 will-change 本身“搞乱层级”，而是它会**强制创建新的层叠上下文（stacking context）**。一旦父元素（比如一个 .card）加了 will-change: transform，它的所有子元素的 z-index 就只在该 .card 内部起作用——哪怕子元素设了 z-index: 9999，也盖不过同级但没被“封住”的兄弟容器（比如另一个没加 will-change 的 .modal）。
常见现象：
- 弹窗里的按钮点不了，被背后某个带
will-change的轮播图遮住 - 下拉菜单展开后瞬间沉底，明明
z-index比导航栏高得多 - 开发者工具里看到目标元素
z-index: 100，但 Computed 面板显示 “Stacking Context: Yes” —— 它已经被“隔离”了
哪些 will-change 值会触发层叠上下文
只要浏览器认为该元素需要独立合成层，就会顺带创建层叠上下文。以下写法都会触发：
-
will-change: transform（最常用，也最容易踩坑） will-change: opacitywill-change: scroll-position-
will-change: transform, opacity（多余项不加分，但照样触发）
will-change: auto 或未声明时，不会创建；但will-change: unset 不等于 auto，慎用。
修复层级错乱的实操路径
别急着删 will-change，先判断是否真需要它：
- 如果只是静态卡片或偶尔 hover 的按钮，**根本不需要**
will-change—— 浏览器自己会优化 - 如果确实要动画（比如侧边栏滑入），优先把
will-change加在**动画主体元素自身**，而不是它的父容器 - 避免在全局类（如
.list-item）上直接写will-change，改用 JS 动态控制：element.style.willChange = 'transform'，动画结束立即设回'auto' - 若必须保留在父容器上，且子元素需跨容器竞争层级，请把关键子元素（如弹窗、Tooltip）**提升到同一层叠上下文根节点下**，比如挂到
body下，而非嵌套在那个带will-change的容器里
验证与调试的关键动作
Chrome DevTools 中真正有用的不是看 Styles 面板的 will-change 是否写了，而是：
- 选中可疑元素 → 右侧 «Layout» 标签页 → 查看是否标记为 “Stacking Context”
- 打开 Rendering 面板 → 勾选 “Layer borders”，观察是否意外多出合成层（绿色边框）
- 临时给父容器加
outline: 2px solid red，确认你操作的确实是“层叠上下文根”，而不是你以为的“子元素”
复杂点在于：will-change 的副作用往往延迟暴露——开发时一切正常，上线后和第三方组件（比如广告 SDK、埋点脚本）一叠加，新旧层叠上下文互相嵌套，层级就彻底不可控了。
