z-index写了却没用是因为元素未定位或被父级层叠上下文“锁死”在局部范围；需确保position非static，并检查opacity、transform等属性是否触发新上下文，再通过DevTools定位并调整对应父容器样式。
z-index写了却没用，不是值不够大，而是目标元素被父级“关进小房间”了——这个房间叫层叠上下文（stacking context），只要它存在，子元素的z-index就只能在房间里比大小，根本出不去。
为什么z-index设了还是被盖住
最常见原因有两个：元素没定位，或它的某个祖先（不一定是直接父级）创建了新层叠上下文。前者直接让z-index失效；后者则把它“锁死”在局部范围里。
-
position: static（默认值）时，z-index完全被忽略，哪怕写成z-index: 9999 - 祖先元素只要满足以下任一条件，就会创建新上下文：
opacity小于1、transform不为none、filter不为none、will-change: transform、isolation: isolate、position: fixed或sticky且z-index非auto -
z-index: 0和z-index: auto效果不同：前者会创建新上下文，后者不会（前提是已定位）
怎么快速定位是哪个父级在“截胡”
打开 Chrome DevTools，选中被遮挡的元素，在右侧面板「Computed」里搜索 stacking context。如果某祖先节点显示 This element establishes a stacking context，它就是问题源头。
- 更直观的方式：打开 «Rendering» 面板 → 勾选 «Show layers panel» → 切换到 «Layers» 标签页，直接看到每个层叠上下文对应的 DOM 节点；点击就能高亮对应元素
- 临时删掉疑似父级的
opacity、transform、filter或will-change，看遮挡是否立刻消失 - 把目标元素剪切出来，直接挂到
<body>下测试——如果此时能正常显示，基本坐实是层叠上下文问题
position: relative 和 position: absolute 怎么选
只为了激活 z-index，优先用 position: relative。它不改变文档流位置，又安全解锁层级控制。
立即学习“前端免费学习笔记（深入）”；
- 用
position: absolute时，必须确保其最近的已定位祖先（比如position: relative）能提供合理参照；否则 top/left 会相对于 viewport 计算，容易错位 - 如果该祖先设置了
overflow: hidden、auto或scroll，会直接裁剪子元素——z-index根本没机会参与绘制 - 别指望靠 HTML 书写顺序来“赌”谁在上，
static元素的层叠行为不可控，尤其混入定位元素后极易出错
数值怎么设才不踩坑
z-index 不是越大越好，而是要分组管理。全局乱用 z-index: 9999 会让后续组件（比如模态框、通知栏）无法插入中间层级。
- 按功能划分区间：例如
--z-header: 100、--z-dropdown: 200、--z-modal: 1000、--z-toast: 1100 - 避免对非必要父容器设
will-change: transform——它比transform更容易隐式创建层叠上下文 - 负值合法，但需配合
overflow: visible父容器，否则会被裁掉；z-index: -1在部分浏览器中行为不一致，慎用
真正难的不是调数字，而是识别哪一层祖先悄悄建了“玻璃罩”。很多时候删掉一行 opacity: 0.99 或 transform: scale(1) 就能解决问题——别急着堆 z-index，先查 stacking context。
