在Safari浏览器中，你可能会遇到一个令人头疼的棘手问题：明明已经写好了 transform-style: preserve-3d，3D立体效果却突然“失效”了。实际上，这并不是代码写错了，而是Safari（尤其是iOS 15-16版本）对CSS规范的校验更加严格：只要父级链中任意一层遗漏了该属性，或者被某个CSS框架重置为 flat，它就会直接退回到平面渲染模式——不会报任何错误，但3D深度信息会彻底丢失。更隐蔽的陷阱在于：Safari要求参与3D变换的元素自身必须拥有明确的 transform 声明（哪怕只是 translateZ(0)），否则不会触发3D渲染上下文。而Chrome则可能“宽容地”继续渲染，从而掩盖了问题。
为什么 Safari 中 transform-style: preserve-3d 会“突然失效”？
根本原因在于Safari对CSS规范的严格校验：只要父级链中任意一层遗漏了 transform-style: preserve-3d，或者被某些CSS框架重置为 flat，它就会直接退化为平面渲染——不会报错，但3D深度信息彻底丢失。更隐蔽的是：Safari要求参与3D变换的元素自身必须有明确的 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作为兜底，尤其对移动端 - 若部分子元素需保留交互，用内联样式局部覆盖：
- 避免在已设
pointer-events: none的父元素上再叠加opacity < 1或will-change，它们可能干扰事件传递链
真正麻烦的从来不是属性没写全，而是你调试时看到“看起来正常”，就以为没问题——其实 Safari 已静默降级为 flat，Chrome 用启发式渲染撑住了表象，而真实遮挡逻辑早已崩坏。
