应主动降级3D效果：优先用@media和prefers-reduced-motion禁用transform-style: preserve-3d与perspective，小屏移除preserve-3d，JS控制需防同步布局。
用 @media 和 prefers-reduced-motion 主动降级 3D 效果
响应式里硬塞 3D 效果，手机卡、老设备闪、甚至触发 iOS Safari 的渲染崩溃——这不是适配，是埋雷。核心思路不是“怎么让 3D 在小屏跑得更好”，而是“什么时候该彻底关掉它”。@media 查屏幕尺寸只是基础，真正关键的是监听用户系统偏好和设备能力。
-
prefers-reduced-motion: reduce是必加兜底：iOS/Android/macOS 用户在系统设置里开了“减少动画”，浏览器会直接暴露这个媒体查询，此时应禁用所有transform: rotateX、perspective、transform-style: preserve-3d - 小屏设备（如
max-width: 768px）建议直接移除preserve-3d，因为多数移动端 WebKit 渲染器对 3D 层叠的合成效率极低，容易掉帧 - 避免用 JS 动态判断
window.innerWidth再改样式——CSS 媒体查询更轻量、无重排、且能被 SSR 正确捕获
哪些 CSS 3D 属性最该优先屏蔽
不是所有 3D 相关声明都一样危险。perspective 和 transform-style 是性能黑洞源头，而单次 rotateY(10deg) 影响相对小。屏蔽策略得按破坏力分级。
- 必须屏蔽：
transform-style: preserve-3d—— 它强制浏览器开启独立 3D 渲染上下文，移动端 GPU 内存占用陡增，常导致页面白屏或强制刷新 - 强建议屏蔽：
perspective值（尤其> 1000px）—— 大 perspective 会让 3D 变换计算精度下降，配合will-change: transform更易触发渲染异常 - 可保留但需简化：
transform中的 3D 函数（如rotate3d()）可降级为 2D（rotate()），但别留translateZ(0)这种伪 3D 提升——现代浏览器已不依赖它触发硬件加速
如何验证屏蔽是否生效
光写 CSS 不代表它真被绕过了。很多开发者以为加了 @media 就万事大吉，结果在 iPhone 上还是卡顿——因为没确认浏览器实际应用的样式。
- 打开 Chrome DevTools → “Rendering” 面板 → 勾选
Emulate CSS reduced motion，看 3D 效果是否消失；再切到 “Device Mode”，选 iPhone SE，检查 computed styles 里transform-style是否回退为flat - 真机测试时重点看
transform计算值：如果降级后仍显示matrix3d(...)，说明某处内联样式或 JS 强制覆盖了 CSS 规则 - 注意 Safari 的一个坑：
prefers-reduced-motion在 iOS 13+ 才稳定支持，旧版本需用@supports not (animation: test)等特性检测做 fallback
JS 动态控制 3D 开关的边界情况
纯 CSS 能解决 90% 场景，但遇到 Canvas + CSS 3D 混合、或需要根据滚动深度渐变启用 3D 时，JS 不可避免。这时关键不是“怎么写”，而是“在哪写、何时写”。
立即学习“前端免费学习笔记（深入）”；
- 绝不在
scroll或resize事件里直接操作style.transform—— 它会强制同步布局，立刻卡死低端安卓机 - 改用
requestAnimationFrame+getBoundingClientRect()判断元素是否进入视口，只在进入后才添加enable-3d类名，由 CSS 控制效果 - 监听
matchMedia('(prefers-reduced-motion: reduce)')的change事件，比轮询window.matchMedia更可靠，且兼容 Safari
preserve-3d 的继承性——父容器设了它，子元素即使没写 3D transform，也会被拖进 3D 上下文。一不留神，整个导航栏就因一个 hover 效果全量降帧。 
