Android 2.x–4.3 WebView 中 translate3d 会强制创建独立层叠上下文但不支持 Z 轴排序，导致 z-index 失效；iOS 则因 3D 投影重排绘制顺序使 z-index 彻底无效，属规范行为而非 bug。
translate3d 在 Android 2.x–4.3 WebView 中触发 z-index 失效
旧版安卓 WebView（特别是 Android 2.x 到 4.3）不支持硬件加速下的独立 3D 层级合成，translate3d() 会强制创建新的层叠上下文，但又不按标准 Z 轴排序渲染。结果就是：z-index 值再大也压不住加了 translate3d(0,0,0) 的兄弟元素。
这不是写错 CSS，而是底层 WebKit 渲染管线缺失 3D 投影能力导致的固有行为。
- Android 4.4+（Chromium 内核）开始逐步修复，但部分定制 ROM 仍沿用旧 WebView
-
translate3d(x,y,z)和translateZ(z)在这些版本中效果等价，都会触发病变式层叠 - 哪怕只写
translate3d(0,0,0)（无实际位移），也会让元素脱离常规 stacking context
为什么加 translate3d(0,0,0) 反而让页面“更卡还错层”
开发者常误以为加 translate3d(0,0,0) 是“开启硬件加速”的万能开关，但在 Android 2.x–4.3 上，它只是把绘制任务甩给 GPU，却没配套的深度缓冲和 Z 排序逻辑——GPU 按 DOM 顺序硬画，后出现的元素直接覆盖前面的，不管 z-index 或 transform-Z。
典型现象：position: absolute; z-index: 9999; 的弹窗被一个只写了 transform: translate3d(0,0,0); 的轮播图盖住。
立即学习“前端免费学习笔记（深入）”；
- 不要在 Android 4.3 及以下环境对交互控件（如按钮、下拉菜单）使用任何
transform，包括空translate3d - 若必须动画，改用
translate()（2D）+will-change: transform（需测试兼容性） - 检测手段：用
navigator.userAgent匹配Android [2-4].[0-3]，然后动态移除或降级 transform
iOS 上 translate3d 导致层级翻转的真正原因
iOS Safari（尤其 iOS 12–15）对 transform-style: preserve-3d 的实现较激进：只要父容器设了 translate3d，子元素即使没写 Z 值，也会被强制提升到独立 3D 层面，且默认 Z=0；多个同级子元素的视觉顺序由它们最终投影后的 Z 坐标决定，而非 z-index。
所以你看到“z-index: 999 也不顶用”，其实是浏览器在按三维空间坐标重排绘制顺序。
- 修复关键：父容器必须设
transform-style: preserve-3d，且子元素显式带translateZ()（如translateZ(1px)和translateZ(2px)） - 避免混用：
translate3d(10px,20px,30px)和单独translateZ(40px)的计算基准可能不一致，统一用后者更可控 - 负 Z 值（如
translateZ(-10px)）在 iOS 旧版中易导致元素消失或闪烁，优先用正值前移
z-index 在 3D 场景中完全失效是设计使然
一旦任意祖先元素设置了 transform、opacity、filter 或 will-change，就会创建新的 stacking context，z-index 只在该 context 内部有效。而 3D 变换进一步让浏览器切换到基于透视投影的合成流程，z-index 彻底退出排序逻辑。
这不是 bug，是规范要求的行为。Chrome DevTools 的「Layers」面板能清晰显示哪些节点已脱离全局 stacking context。
- 检查路径：右键元素 → “Inspect” → 右侧「Computed」→ 拉到底看「Stacking Context」来源
- 常见隐形触发器：
opacity: 0.99、transform: translateZ(0)、filter: blur(0.5px) - 真要全局置顶（比如 toast 提示），放弃 3D，改用
position: fixed; z-index: 2147483647;并确保其父容器无任何 stacking context 触发属性
