z-index无效是因为它仅对已定位元素生效，且只在同一个层叠上下文中起作用；若父容器设置了opacity、transform等属性，会创建新上下文，将子元素z-index“锁死”在其内部。
z-index为什么写了却没用
因为z-index只对已定位元素生效，且只在**同一个层叠上下文**里起作用。你给.dropdown-menu设了z-index: 9999，但如果它的父容器设置了opacity: 0.99、transform: scale(1)或filter: blur(0)，这个父容器就创建了新的层叠上下文——子元素的z-index被“锁死”在里面，根本出不去。
常见错误现象包括：
- DevTools里看到元素的
z-index显示为auto（not applicable） - 遮挡它的兄弟元素
z-index: 10，而它自己是z-index: 20，依然被盖住 - 删掉父级一行
will-change: transform，遮挡立刻消失
怎么快速定位哪个父级在“截胡”z-index
打开 Chrome DevTools，选中被遮挡的元素，在右侧面板「Computed」里搜索stacking context。如果某祖先节点显示 This element establishes a stacking context，它就是问题源头。
更直观的方式是打开 «Rendering» 面板 → 勾选 «Show layers panel» → 点击 «Layers» 标签页，直接看到每个层叠上下文对应的 DOM 节点。被遮挡元素如果出现在底层，说明它被某个父级“关进小房间”了。
实操建议：
- 临时注释掉父级的
opacity、transform、filter、will-change等样式，看遮挡是否消失 - 把目标元素剪切出来，直接挂到
下测试，验证是否真由层叠上下文导致 - 避免对非必要父容器设
will-change: transform——它比transform更容易隐式创建层叠上下文
position: relative 和 absolute 哪个更适合解锁z-index
只要是为了控制层级，优先加position: relative。它不改变文档流位置，又能激活z-index，最安全。
用position: absolute时要特别注意：
- 必须确保其最近的已定位祖先能提供合理参照（比如
position: relative） - 如果该祖先设置了
overflow: hidden、auto或scroll，会直接裁剪子元素——z-index根本没机会参与绘制 - 别指望靠“后写的 static 元素一定在上”，这是不可控的 fallback 行为
z-index数值怎么设才不踩坑
不是越大越好，而是要分组管理。全局乱用z-index: 9999会导致后续组件（比如模态框、通知栏）无法插入中间层级。
推荐按功能划分区间：
--z-header: 100--z-dropdown: 200--z-modal: 1000--z-toast: 1100
还要注意：z-index: auto和z-index: 0效果不同——前者不参与层叠排序，后者明确进入当前上下文的“默认层”。负值合法，但需配合overflow: visible父容器，否则会被裁掉。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
