z-index 在 Safari 等浏览器中“失效”是因为祖先元素触发了层叠上下文，使子元素 z-index 仅在内部生效；需检查 opacity<1、transform、filter 等属性，并用 DevTools 确认 stacking context。
z-index 在 Safari 或旧版 Chrome 里“失效”，不是你写小了，而是某个祖先元素在浏览器渲染时悄悄创建了独立的层叠上下文（stacking context），把目标元素锁在里面——它再怎么调 z-index: 9999，也出不去和外面比高低。
为什么 Safari 里 z-index 看着就是压不住元素
Safari（尤其是 iOS/iPadOS WebKit）对触发 stacking context 更敏感：哪怕父元素只写了 opacity: 0.99、transform: translateZ(0) 或 filter: blur(0.1px)，就会立刻建起隔离“盒子”。Chrome 常宽容地不截断，导致同一份 CSS 在 Safari 里层级崩塌。
- 用 Safari 开发者工具 → Elements → 右侧 Styles 面板，直接看是否有 “Stacking Context” 标识
- 重点检查那些没写
z-index却突然标为 “Yes” 的父节点——大概率是transform或opacity搞的鬼 - 别用
translateZ(0)强制硬件加速：现代 Safari 已默认启用 GPU 合成，它只带来副作用，不提升性能
如何快速确认是不是 position 没生效
z-index 对 position: static 元素完全无效，连计算样式里都不显示该值。Safari 尤其严格，哪怕多一个空格（如 position: relative ;）也可能回退为 static。
- 打开 DevTools 的 Computed 面板，搜
position，确认最终值是relative、absolute、fixed或sticky，不是static - JS 动态插入的弹窗/tooltip，必须同步设置
position: relative，不能只靠 class；否则 Safari 可能在 layout 完成前就按static处理 -
position: sticky在 Safari 中行为不稳定：超出滚动容器时会退化为relative，若父容器没设z-index，整个 sticky 块就失去层级控制权
父级 opacity/transform 导致子元素 z-index 被截断
只要任意祖先满足以下任一条件，就会创建新 stacking context：opacity < 1、transform != none、filter != none、will-change、isolation: isolate。此时子元素的 z-index 只跟兄弟比，盖不过外部同级元素。
立即学习“前端免费学习笔记（深入）”；
- 临时注释掉父级的
opacity或改用rgba(0,0,0,0.99)（不触发上下文），观察遮挡是否消失 - 若必须保留透明效果，就在该父容器上显式加
z-index: 0+position: relative，把它变成可参与外层比较的上下文根 -
z-index: 0和z-index: auto效果不同：前者强制创建新上下文，后者不会（前提是元素已定位）；误加z-index: 0是常见隐形坑
iframe/video 天然高于 z-index，这不是 bug 是设计
在 Safari 15 及更早版本中，<iframe>、<video>、<select> 属于“插件窗口层”，渲染优先级硬编码在 WebKit 底层，z-index 完全无效。
- 检查页面是否嵌入 YouTube/Vimeo
<iframe>，或用了<video>全屏 API；即使z-index: 99999也压不住 - 临时方案：用 JS 控制
<iframe>的visibility: hidden或display: none，再显示遮罩层 - 若必须重叠，考虑给
<iframe>加allow="fullscreen; clipboard-write"，并配合document级事件做交互降级
真正难的不是堆数字，而是看清 DOM 路径上哪一层悄悄关上了门——transform、opacity、filter 出现的位置，往往就是层级断裂的起点。
