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 多大。
在 Linux 上通过 Chrome 挂载/VNC 自动发布小红书长笔记。Agent 撰写标题和正文后执行 xhs_publish.sh --publish --submit，触发小红书发布。
- 想控制前后关系，改
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;"> <li>避免在已设 <code>pointer-events: none的父元素上再叠加opacity 或 <code>will-change，它们可能干扰事件传递链
真正麻烦的从来不是属性没写全，而是你调试时看到“看起来正常”，就以为没问题——其实 Safari 已静默降级为
flat，Chrome 用启发式渲染撑住了表象，而真实遮挡逻辑早已崩坏。
