fixed元素被遮挡主因是祖先触发层叠上下文，常见于opacity、transform等样式；iOS Safari中fixed+transform组合会导致z-index失效，可用overflow:hidden或translateZ(1px)缓解。
fixed元素被遮挡，其实是祖先触发了层叠上下文
不是z-index没写对，而是某个看不见的父级（哪怕隔了三四层）悄悄创建了新的层叠上下文，把position: fixed元素“锁死”在局部层级里。常见诱因包括：opacity: 0.99、transform: scale(1)、filter: blur(0)、will-change: transform，甚至isolation: isolate。
用浏览器开发者工具的「Computed」面板逐级检查祖先元素，看是否有stacking context: yes。重点盯住那些看似无害的样式——比如给轮播容器加了个transform: translateZ(0)来“强制硬件加速”，结果反而截断了z-index全局比较。
Safari下fixed + transform组合会绕过z-index
iOS 15+ 和 macOS Safari 中，如果fixed元素自身或其任意祖先设置了transform（哪怕只是translateY(0)），且页面可滚动，z-index就可能完全失效：元素会被地址栏、键盘或原生 UI 遮挡，调高数值也无效。
两种实操解法：
立即学习“前端免费学习笔记（深入）”；
- 给最近的非
body祖先加overflow: hidden（最稳妥，但可能影响滚动或裁剪） - 给
fixed元素自己加transform: translateZ(1px)（轻量，但慎用于动画中，避免触发频繁重绘）
z-index生效的前提常被忽略
z-index只对已定位元素起作用。这意味着：
-
position: static元素设z-index等于没写 - 遮挡
fixed元素的其他内容，也必须设position: relative或absolute才能参与同一层级排序 - 别给
fixed元素的直接父容器设z-index——它反而会框定子元素的层级上限
数值本身不重要：z-index: 100和z-index: 9999在同一个上下文中效果一样，关键是比较关系。
移动端fixed定位的隐藏陷阱
在 iOS Safari 上，fixed元素若同时用了transform，且页面存在滚动，它的渲染行为会脱离标准层叠逻辑。此时即使z-index再大，也可能被系统 UI 或第三方键盘压住——这不是 bug，是 WebKit 的渲染策略限制。
真正有效的应对不是堆数值，而是规避组合：要么移除transform，要么改用position: sticky替代（需确认目标设备支持），或者用top/left配合margin-top模拟固定效果。
