Safari 中 z-index 常不生效，因其对层叠上下文触发更敏感；z-index 仅在同层叠上下文中有效，transform、opacity、filter 等会意外创建新上下文，隔离子元素层级。
为什么 z-index 在 Safari 里经常不生效
因为 Safari（尤其是 iOS/iPadOS 的 WebKit）对层叠上下文（stacking context）的触发更敏感，z-index 只在**同层叠上下文内**起作用。一旦父元素因 transform、opacity、filter 等属性创建了新层叠上下文，子元素的 z-index 就只能在该局部上下文中排序，无法突破到外层。
常见诱因包括：transform: translateZ(0)、transform: scale(1)、will-change: transform —— 它们本意是“启用 GPU 加速”，却意外隔离了层叠关系。
- 检查是否对某个祖先元素加了
transform或will-change，哪怕只是translateZ(0)，都可能切断z-index的跨层级作用 - 用 Safari 开发者工具 → Elements → Styles 面板，看元素右侧是否标有 “Stacking Context” 提示
- 临时移除疑似触发层叠上下文的样式，确认
z-index是否恢复预期行为
什么时候该用 translateZ(0)，什么时候不该用
translateZ(0) 是 WebKit 时代常用的“强制硬件加速”技巧，但现在已过时且副作用明显：它会无条件创建新的层叠上下文，同时增加内存开销和合成图层数量。
- 现代 Safari（iOS 15.4+ / macOS Monterey+）已默认优化动画性能，绝大多数场景下不需要
translateZ(0) - 仅在极少数滚动卡顿严重、且确认是 CPU 渲染瓶颈时，才考虑对加
transform: translateZ(0)，并确保其父容器未设z-index或其他层叠干扰属性 - 若需兼容老版 Safari（如 iOS 12），优先用
will-change: transform替代translateZ(0)，但必须在动画开始前设置、结束后清除，否则持续占用 GPU 资源
真正可控的层叠修复方案
与其反复调试 translateZ 和 z-index 组合，不如从结构上收拢层叠控制权：
立即学习“前端免费学习笔记（深入）”；
- 把所有需要参与全局层叠排序的定位元素，提升到同一个“层叠容器”下（例如一个全屏
position: relative的#overlay-root） - 在这个容器内，用
z-index做线性管理，比如：.modal { z-index: 100; }、.tooltip { z-index: 90; }、.loading { z-index: 80; } - 避免在中间层级使用
transform、opacity: 0.99、filter: blur(0)—— 这些都会悄悄创建新层叠上下文 - 必要时用
isolation: isolate显式隔离不需要参与层叠的区域，防止意外污染
Safari 调试时容易忽略的关键点
WebKit 的层叠渲染逻辑和 Chrome 不完全一致，尤其在混合 position: fixed 和 transform 时：
-
position: fixed元素在 Safari 中可能被transform父级“捕获”，变成相对定位效果 —— 检查是否误将fixed元素嵌套在transform容器里 - 使用
-webkit-overflow-scrolling: touch的滚动容器，内部z-index行为异常，建议改用原生overscroll-behavior - 动态插入的元素（如 JS 创建的 tooltip），Safari 可能延迟创建层叠上下文，首次显示时
z-index失效，可加setTimeout(() => el.style.zIndex = '99', 0)强制重排
最稳妥的做法，是让层叠关系尽可能扁平、显式、无依赖。复杂嵌套 + 层叠上下文 + 动态插入，三者叠加时 Safari 几乎必然出问题。
