移动端z-index失效主因是父级创建了独立层叠上下文，而非数值过小；需检查position是否非static、向上排查触发上下文的父元素（如transform/opacity/filter），并用Portal/Teleport将浮层提至body。
移动端 z-index 失效，几乎从不因为数值写小了，而是目标元素被父级“关进了一个独立层叠上下文里”——它再高，也出不去那个盒子。
为什么加了 z-index 还是被盖住？先看 position 是否生效
浏览器压根不读 z-index，只要元素的 position 是 static（默认值）。这不是“没效果”，是“不参与层叠计算”。
- 用 DevTools 选中元素，在「Computed」面板搜
position，如果显示static，z-index就等于没写 - 动态插入的浮层（如 toast、picker）常漏掉
position，JS 设置样式时必须显式加position: relative或position: fixed -
display: flex或grid的子项，即使没设position，也能用z-index控制内部顺序，但依然受父级层叠上下文隔离——这点容易误判
父元素用了 transform: translateZ(0) 就危险了
这个写法在 iOS Safari 中会静默创建新层叠上下文，且让 position: fixed 元素降级为 absolute 行为。不是“加速有用”，是“结界已立”。
- 现象：
z-index: 9999的 Modal 按钮始终被 header 盖住；DevTools 里z-index显示为(not applicable)或灰显 - 临时验证：注释掉父级的
transform，立刻恢复覆盖——这是最快确认手段 - 别信
will-change: transform更安全，它和translateZ(0)触发机制一致，同样建“结界” - 常见陷阱：Bootstrap 的
.fade类、Vue 组件的过渡动画、React 中带opacity的 wrapper，都可能悄悄触发
怎么定位哪个父级在“拦路”？
别从目标元素往下调 z-index，要往上翻 DOM 树，找第一个“突然变成层叠上下文根”的节点。
- 在 Chrome DevTools 的 Elements 面板中，逐级点击父节点，右侧面板 Layout 标签页下看「Stacking context」是否变为
Yes - 重点盯那些没写
z-index却显示Yes的父元素——大概率是它用了opacity: 0.99、filter: blur(0)或transform: scale(1) - 这些属性只要偏离初始值就触发：比如
opacity: 0.999、transform: rotate(0.0001deg)，看着无害，实则致命 - 注意：
z-index: 0和z-index: auto效果不同——前者强制创建上下文，后者不创建；别以为加个 0 很稳妥
iOS Safari 特别要防 fixed 元素被“降级”
只要父容器有 transform、opacity 或 <code>filter，iOS Safari 就可能忽略 position: fixed 的语义，让它退化为 absolute，失去视口定位能力。
- 修复不能只靠改
z-index，得让目标元素既“能定位”，又“不被关住” - 若父容器必须保留动效（如轮播卡片），就把浮层（tooltip、dropdown）用 JS 提到
document.body下，再手动算top/left - 用
createPortal（React）或Teleport（Vue）是最稳妥方案，但要注意滚动偏移：需监听window.scrollY并实时更新定位 - 避免给
fixed元素的直接父级加任何可能触发上下文的样式——哪怕只是opacity: 0.999
真正难的不是堆出 z-index: 999999，而是看清哪一层 DOM 节点上，悄悄加了一行 transform: translateZ(0) 或 opacity: 0.99，然后把它揪出来。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
