唯一可靠依据是调用canvas.getContext('webgl')或'webgl2'并检查返回值是否为truthy，若为null则需降级至CSS3 3D或Canvas 2D方案。
直接看 canvas.getContext('webgl') 是否返回有效对象——这是判断硬件图形能力是否可用的唯一可靠依据，其他指标（如设备型号、UA 字符串、devicePixelRatio）都不能替代这一步。
检测 WebGL 支持必须显式调用 getContext
浏览器可能启用 WebGL 但禁用 GPU 加速，或在某些 WebView/鸿蒙低版本中仅返回 null。不能依赖 navigator.gpu（尚未广泛支持）或 WebGLRenderingContext 构造函数。
- 必须写成
const gl = canvas.getContext('webgl') || canvas.getContext('webgl2')，并检查gl是否为 truthy 值 - 若返回
null，说明当前环境不具备可用的硬件加速渲染通路，应 fallback 到 CSS3 3D 或 Canvas 2D 方案 - 部分安卓平板在 Chrome 自定义 Tab 或旧版 WebView 中会静默失败，需在真实设备上验证，不能只靠桌面模拟器
WebGL1 vs WebGL2 的实际分界点在纹理与精度
WebGL2 并非只是“更快的 WebGL1”，它引入了整数纹理、uniform buffer objects、更严格的浮点精度控制等特性，直接影响复杂 3D 动画的稳定性。
- 使用
THREE.WebGLRenderer({ antialias: true })时，若 WebGL2 不可用，抗锯齿可能在某些 Intel 集显上失效，边缘出现明显走样 - 涉及大量贴图采样（如 PBR 材质、法线贴图）的场景，WebGL1 下
texture2D返回值可能因精度截断导致明暗异常，WebGL2 的highp默认保障更可靠 - Three.js v150+ 默认优先尝试 WebGL2，但若检测失败会自动降级；BabylonJS 则需手动传入
{ webGLVersion: 2 }参数才启用 WebGL2 特性
低端设备 fallback 到 CSS3 3D 时要避开常见陷阱
CSS3 3D 不是“简化版 WebGL”，它没有深度缓冲、不支持光照模型、无法做逐像素计算，但对轻量交互动画（翻转、倾斜、视差）足够高效。
立即学习“前端免费学习笔记（深入）”；
- 必须设置
transform-style: preserve-3d，否则子元素会被强制扁平化到父容器平面，3D 变换失效 -
perspective值不宜过小（如100px），否则在高 DPR 屏幕上易触发渲染层溢出，造成闪烁或裁剪 - 避免在
:hover中同时操作多个transform属性（如 rotateX + translateZ + scale），某些 iOS Safari 会丢帧；改用单个transform字符串拼接更稳妥 - CSS3 3D 无法响应
requestAnimationFrame精确帧率控制，动画节奏由浏览器合成器决定，不适合需要严格时间同步的场景（如音频可视化）
Canvas 2D 作为兜底方案时性能关键在重绘粒度
当 WebGL 和 CSS3 3D 都不可用（如老旧 Win7 + IE11 或极低端 Android 4.4 WebView），Canvas 2D 是最后防线，但容易因误用迅速卡顿。
- 禁止在
requestAnimationFrame中调用ctx.clearRect(0, 0, canvas.width, canvas.height)全屏擦除，改用ctx.clearRect(x, y, w, h)局部清除变化区域 - 避免每帧重复设置
ctx.fillStyle、ctx.font等状态属性；可提前缓存ctx.fillStyle = '#f00'，而非每次绘制前赋值 - 文字渲染慎用
ctx.fillText()，尤其含中文时；先用ctx.measureText()预估宽度，再结合ctx.textBaseline控制对齐，否则不同设备上 baseline 偏移不一致 - Canvas 2D 没有层级概念，若需叠加背景/主体/控件，必须手动管理多层
<canvas></canvas>元素并按序drawImage()合成
真正难处理的不是“有没有 WebGL”，而是混合场景下如何让同一套动画逻辑在 WebGL / CSS3 / Canvas 三者间无缝迁移——这意味着你要把变换矩阵、时间轴、事件坐标映射都抽离为独立模块，而不是把渲染细节写死在动画主循环里。
