z-index不生效的主因是父容器创建了新层叠上下文或元素未设非static定位；需检查opacity、transform等触发属性及position值，并用DevTools Layers面板排查层叠结构。
z-index 不生效？先确认父容器是否创建了新的层叠上下文
很多情况下 z-index 看似写了但完全没用，根本原因不是值设小了，而是它所在的元素被包裹在一个已创建层叠上下文的父级里——比如父元素设置了 opacity 小于 1、transform、filter、will-change，或者本身就是 position: fixed/absolute 且带 z-index。这时子元素的 z-index 只在该父容器内部起作用，无法和外部其他兄弟容器比高低。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 用浏览器开发者工具检查目标元素的“Computed”面板，看
z-index是否显示为 “auto” 或被灰掉 - 往上逐级查看父元素的
transform、opacity、filter等属性，哪怕只是opacity: 0.99也会触发新层叠上下文 - 若必须保留这些视觉效果，可把需要提层的元素“提出来”，用
position: fixed或挂到body下，再用 JS 动态同步位置（慎用）
CSS 中 z-index 的数值比较只在同层叠上下文中有效
z-index 不是全局绝对排名，而是一场“局部选举”。两个元素即使数值差 1000，只要不在同一个层叠上下文里，就互不干扰。典型场景：弹窗（modal）被遮罩层（overlay）盖住，但遮罩层的 z-index 实际比弹窗小——因为遮罩层和弹窗分属不同父容器，各自父容器的层叠顺序决定了最终谁在上。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 避免跨多层嵌套盲目堆高
z-index值（如 9999、99999），这会让后续维护失控 - 统一规划几档基础层级，例如：
--z-nav: 100、--z-modal-overlay: 1000、--z-modal-content: 1001，用 CSS 自定义属性管理 - 当发现两个组件总打架，优先检查它们最近的共同祖先是否意外创建了层叠上下文
position 属性是 z-index 生效的前提
z-index 对 static 定位元素完全无效——这是最常被忽略的硬性前提。哪怕你给一个 div 设置了 z-index: 9999，只要它没设 position（或设的是默认的 static），这个值就只是摆设。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 检查目标元素的
position值，确保是relative、absolute、fixed或sticky - 不要依赖框架组件默认的
position，比如某些 UI 库的Dialog内部节点可能未设定位，需手动加position: relative - 注意
position: sticky虽然能用z-index，但它只在粘性生效区域内参与层叠，超出后行为会回退到文档流顺序
Flex/Grid 容器中的 z-index 行为与文档流一致，但容易误判
在 display: flex 或 display: grid 的容器里，子项的 z-index 依然生效，且遵循“后声明的子项默认在前”的渲染顺序（即 HTML 中靠后的元素层叠在上）。但很多人以为 Flex/Grid 会自动重排层叠顺序，结果发现明明 z-index 设得高，还是被盖住——其实只是它在 HTML 里写得太靠前了。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- Flex/Grid 子项的
z-index优先级高于 DOM 顺序，但前提是它们属于同一层叠上下文；否则仍按父容器层级算 - 不要依赖
order属性改变视觉顺序来调整覆盖关系，order不影响层叠上下文，也不改变z-index的比较逻辑 - 调试时临时加
outline: 1px solid red和background: rgba(0,0,0,0.1)，比单看z-index数值更能暴露真实渲染顺序
真正难的不是记住 z-index 要配 position，而是当多个第三方组件嵌套在一起时，你很难一眼看出哪一层悄悄创建了层叠上下文。这时候比改代码更有效的，是打开 DevTools 的“Layers”面板（Chrome），直接看层叠树结构。
