为什么CSS 3D转换在某些浏览器中会产生层级遮挡错误？

Safari中transform-style: preserve-3d“突然失效”是因为其对规范校验更严格：父链任一层漏设或被重置为flat即退化为2D渲染，且要求参与变换的元素自身必须有transform声明（如translateZ(0)），否则不触发3D上下文；Chrome则可能宽容渲染掩盖问题。

为什么 Safari 中 transform-style: preserve-3d 会“突然失效”？

不是代码写错了，而是 Safari（尤其 iOS 15–16）对 transform-style: preserve-3d 的规范校验更严格：只要父链中任意一层漏设该属性、或被 CSS 框架重置为 flat，它就直接退回到平面渲染，不会报错，但 3D 深度信息彻底丢失。

更隐蔽的是：Safari 要求参与 3D 变换的元素自身必须有明确的 transform 声明（哪怕只是 transform: translateZ(0)），否则不触发 3D 上下文。Chrome 则可能“宽容地”继续渲染，掩盖了问题。

• 检查所有父容器是否都显式设置了 transform-style: preserve-3d，不能只设最外层
• 确认没有中间层被 transform-style: flat 覆盖（比如某些 UI 库的 reset.css）
• 给每个需要深度排序的子元素加一个无感 transform: translateZ(0)，强制 Safari 认可其 3D 身份

z-index 在 3D 环境里为什么完全不生效？

z-index 在启用 preserve-3d 的容器内基本失效——这不是 bug，是设计使然。浏览器此时按真实 3D 空间中的 z 坐标排序，而不是 HTML 顺序或 z-index 值。

你调 z-index: 9999，但元素经过 rotateX(45deg) translateZ(-100px) 后实际 z 值可能变成 -150，它就会被画在更远的位置，无论 z-index 多大。

立即学习“前端免费学习笔记（深入）”；

• 想控制前后关系，改 transform 中的 translateZ() 或整体 z 分量，别碰 z-index
• 两个兄弟元素都启用了 preserve-3d，谁离观察者近（变换后 z 值更大），谁就在前面
• 如果必须绕过 3D 排序，把元素移出 preserve-3d 容器（比如用 position: fixed 挂到 body 下）

backface-visibility: hidden 为什么不是“可选优化”？

它不只是隐藏背面，更是告诉浏览器：“这个面不可见”，从而激活正确的背面剔除和深度缓冲计算。不设它，两个旋转面在交叠区域容易出现闪烁、穿模、遮挡错乱——尤其在 Chrome 和 Safari 渲染策略不一致时。

常见误操作是只给翻转容器设 perspective，却忘了给每个翻转面（.front / .back）单独加 backface-visibility: hidden。

• 每个参与 3D 变换且可能被旋转到背面的元素，都应设 backface-visibility: hidden
• perspective 建议设在共同父容器上，值取 1000px～2000px 较稳；太小（如 10px）会导致深度判断抖动
• iOS Safari 对 backface-visibility 更敏感，漏设时问题比桌面端更明显

pointer-events: none 为什么在 iOS Safari 上有时不生效？

部分 iOS Safari 版本（尤其是 15.x 早期）对 pointer-events: none 的实现存在兼容性缺陷，导致事件仍被拦截。这不是配置错误，是浏览器本身的 bug。

典型现象：CSS3DRenderer 渲染的标签盖在 ThreeJS 画布上，设了 pointerEvents = 'none'，PC 端正常，iOS 上点击仍没反应。

• 必须配合 touch-action: none 作为兜底，尤其对移动端
• 若部分子元素需保留交互，用内联样式局部覆盖：<div style="pointer-events: auto;">
• 避免在已设 pointer-events: none 的父元素上再叠加 opacity < 1 或 will-change，它们可能干扰事件传递链

真正麻烦的从来不是属性没写全，而是你调试时看到“看起来正常”，就以为没问题——其实 Safari 已静默降级为 flat，Chrome 用启发式渲染撑住了表象，而真实遮挡逻辑早已崩坏。