iOS Safari中z-index失效主因是父元素transform（如translateZ(0)）创建新层叠上下文，而非z-index值小；应避免滥用transform强制加速，改用will-change并及时清除，统一z-index范围0–9，将需全局排序元素提至同一无上下文根节点。
z-index在iOS Safari里突然不生效，大概率是translateZ(0)惹的祸
不是z-index设小了，而是父元素加了transform: translateZ(0)，悄悄创建了一个新层叠上下文，把子元素“关进盒子”里了。WebKit（Safari底层）对这类触发特别敏感，哪怕只是translateZ(0)，也会无条件隔离z-index作用域。
常见错误现象：.modal写了z-index: 999，但被.header盖住；开发者工具里看到z-index灰显或标为“(not applicable)”；移除父元素的transform后立刻恢复正常。
- 别再全局加
transform: translateZ(0)做“强制硬件加速”——它已过时，副作用明确：创建层叠上下文 + 增加图层数 + 占内存 - 如果真需要提升渲染性能，优先用
will-change: transform，且必须在动画开始前设置、结束后清除（否则GPU持续占用） - 检查所有祖先元素的
Computed样式，重点看transform、opacity、filter是否非默认值
iOS 16+ Safari中z-index值越大反而越容易失效
给.navbar设z-index: 9999，不如设z-index: 8可靠。iOS 16起，Safari对高z-index值的解析更保守，尤其当多个层叠上下文并存时，超大数值可能触发内部排序异常或截断。
使用场景：固定导航栏被section或#tsparticles遮挡，即使z-index差2个数量级也无效。
立即学习“前端免费学习笔记（深入）”；
- 统一收口到0–9范围：比如
body背景设z-index: 0，内容区z-index: 1，弹窗z-index: 5，顶部导航z-index: 8 - 避免
z-index: -1用于背景容器——它会创建独立层叠上下文，且和正数区间无法线性比较 - 同一DOM层级的兄弟元素，只要没跨上下文，
z-index: 9一定压过z-index: 8，无需堆数值
scroll-view或fixed元素内部z-index被截断
scroll-view（uni-app）、position: fixed容器、甚至display: flex子项，都可能因自身属性隐式创建层叠上下文，导致其子元素的z-index只在内部有效。
典型表现：uni-app中uv-picker弹层被.footer-buttons（z-index: 40）遮挡，但picker自身z-index: 15在父容器内已是最高——问题不在值，而在“比的不是同一个榜”。
- 对
scroll-view，临时关闭弹性滚动：-webkit-overflow-scrolling: auto可恢复z-index穿透 - 避免在
position: fixed父容器里再设transform或opacity，否则子元素z-index彻底失效 - flex/grid容器中，子元素若要参与全局层叠，必须确保父容器未创建新上下文（即不满足前述触发条件）
真正有效的层级管理：结构先行，而非调参
靠反复改z-index数字、加!important、塞translateZ，只会让问题更难定位。WebKit的层叠逻辑不等同于Chrome，它更依赖DOM结构与上下文边界。
最省力的做法是把所有需全局排序的定位元素，提到同一个“层叠根”下，例如：
<div id="overlay-root" style="position: relative; z-index: 0"> <div class="modal" style="position: absolute; z-index: 5"></div> <div class="tooltip" style="position: absolute; z-index: 3"></div> </div>
- 这个
#overlay-root不设transform、opacity、filter，也不嵌套在其他可疑上下文中 - 所有弹窗、提示、加载态都挂载到这里，z-index在线性范围内管理（如5/3/1），不再跨层博弈
- 用
isolation: isolate主动隔离不需要参与层叠的区域（如动画模块），防止意外污染
真正难的不是写对某一行CSS，而是识别出哪一层父元素正在静默地重置整个z-index游戏规则。
