z-index无效的根本原因是元素未定位或父级创建了堆叠上下文。必须设置position（如relative）才能生效；父元素的opacity、transform等会创建新堆叠上下文，使子元素z-index仅在内部生效；select/iframe等原生元素不受z-index控制。
直接写style="z-index: 999"却无效？先看position有没有设
浏览器对style里写的z-index完全不买账，如果元素没定位——也就是position还是默认的static，那这行样式等于没写。你甚至能在 DevTools 的「Computed」面板里看到z-index显示为auto，而position是static。
实操建议：
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
- 立刻补上
style="position: relative; z-index: 999"（最安全，不破坏布局） - 别只靠
!important硬顶——它压不住position缺失这个根本问题 - 框架里用
v-bind:style或className动态加样式时，检查是否被组件内联样式覆盖了position
z-index数值再大也盖不住？查父级有没有悄悄建“隔离卡”
你写了style="z-index: 999999"，结果被一个z-index: 1的弹窗蒙层压住——不是数值不够，是你们根本不在同一个“楼层”。父容器只要带了opacity: 0.99、transform: translateZ(0)、will-change: transform，或者position: relative; z-index: 1，就自动成了新堆叠上下文（stacking context），子元素的z-index只能在它内部比大小。
实操建议：
- 打开 DevTools → 选中按钮 → 「Computed」→ 搜索
stacking context，看哪一级被标红了 - 临时注释掉疑似父级的
opacity或transform，观察按钮是否突然浮出 - iOS Safari 尤其敏感，哪怕只是
transform: translateX(1px)也可能触发新上下文
按钮和select、iframe重叠时z-index完全失效怎么办
这不是 bug，是浏览器规范：原生select、iframe、object属于“有窗口元素（windowed element）”，天生渲染在所有 CSS 层之上，z-index对它们无效。你改父容器的z-index、改按钮的z-index、甚至改整个body的z-index，都没用。
实操建议：
- 遮盖
select：用visibility: hidden临时隐藏它（比display: none更安全，不触发重排） - 替代
select：用div+ul实现自定义下拉，完全受z-index控制 - 覆盖
iframe：必须在同级 DOM 插入遮罩层（比如紧挨着iframe后面加一个div.overlay），且该遮罩的父容器不能有opacity 或<code>transform
动态点击置顶按钮时z-index失效的常见原因
用户点一下按钮想让它“浮到最前”，JS 里执行el.style.zIndex = "1000"，结果没反应——大概率因为按钮本身或某级父容器已经处于某个堆叠上下文中，单纯改按钮的z-index只影响它和兄弟元素的顺序，不改变整个上下文对外的层级位置。
实操建议：
- 给按钮加一个高优先级 class（如
.top-layer），样式含position: relative; z-index: 1000;，确保选择器权重足够 - 若按钮在
.modal里，而你想让它盖过另一个.header里的元素，得同时提升.modal和.header的z-index，而不是只动按钮 - 移动端 Safari 对频繁修改
z-index敏感，可配合el.style.willChange = "auto"重置渲染状态
z-index写多大，而是那个没显式声明、却因opacity: 0.99或transform悄悄当了“小 boss”的父容器。调层级，本质是调试整条 DOM 嵌套链上的堆叠上下文归属。前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
