JavaScript 通过 WebXR API 调用设备传感器实现真 AR/VR，而非模拟；WebXR 是 W3C 标准，统一接口，支持平面检测、锚定、姿态追踪；需处理兼容性与降级策略。
JavaScript 本身不直接实现 AR/VR，而是通过 WebXR API（浏览器原生支持的接口）调用设备能力，在网页中构建沉浸式 3D 场景。它不是靠“模拟”，而是真正连接手机陀螺仪、VR 头显姿态、手柄输入、环境光照甚至平面检测（AR），让网页内容响应真实物理空间。
WebXR 是什么：浏览器里的 AR/VR 通行证
WebXR 是 W3C 标准，统一了以前分散的 WebVR/WebAR 接口。它不依赖插件或 App，只要浏览器支持（Chrome、Edge、Firefox on Android / Quest / Windows MR），就能用 JavaScript 启动会话：
-
XRSession 是核心：调用
navigator.xr.requestSession('immersive-ar')或'immersive-vr'，获得设备追踪权限 - 场景渲染不再用普通 canvas，而是绑定到 XRWebGLLayer，确保每一帧都按头显/手机视角实时重绘
- 所有空间数据（位置、旋转、视图矩阵、投影矩阵）由浏览器底层从传感器计算后提供，JS 只负责使用，不自行融合 IMU 数据
实现 AR 的关键三步：识别平面 + 锚定物体 + 跟随现实
以 WebXR AR（如 Chrome for Android）为例，重点不在画模型，而在“粘得牢”：
-
启用 plane detection：创建 session 时传入
{requiredFeatures: ['plane-detection']} -
监听锚点生成：通过
session.addEventListener('xrsessionupdate', e => { ... })获取新检测到的平面（e.planeAnchor），再用session.addAnchor()固定虚拟物体坐标 -
持续对齐现实：每帧调用
frame.getPose(referenceSpace, xrReferenceSpace)，拿到当前帧下物体相对于真实平面的姿态，更新 Three.js 或 Babylon.js 中 mesh 的 position/quaternion
VR 沉浸感来自“零延迟 + 空间音频 + 自然交互”
VR 不是把屏幕变大，而是切断视觉参照、用双目视差+头部运动反馈欺骗前庭系统：
立即学习“Java免费学习笔记（深入）”；
-
帧率与延迟必须硬保障：WebXR 强制要求 72Hz/80Hz/90Hz 渲染，且 JS 必须在
requestAnimationFrame的 XR frame callback 内完成全部逻辑+渲染，超时会丢帧、引发眩晕 -
空间音频需配合位置：用 Web Audio API 的
PannerNode，将音源 position/orientation 绑定到 XRFrame 中获取的玩家头部 pose，声音随转头自然变化 -
手柄交互要物理可信：监听
inputSources（如 Oculus Touch、Quest 控制器），读取gamepad.axes和gamepad.buttons，用射线（raycaster）判断是否“指向并点击”3D 物体，而非鼠标悬停
不复杂但容易忽略：兼容性与降级策略
WebXR 尚未全平台覆盖，实际项目必须考虑 fallback：
- 用
navigator.xr?.isSessionSupported(type)预检支持度，AR 在 iOS Safari 仍需 WebKit 实验性开启，VR 在桌面 Chrome 需启用chrome://flags/#webxr - 无 XR 支持时，自动切换为 3D 模式（OrbitControls + 鼠标拖拽） 或 360° 全景图（Three.js TextureLoader + SphereGeometry），保留基础体验
- 移动端优先检测
screen.orientation和deviceMotion，用陀螺仪简易模拟 AR（虽无平面检测，但能实现“手机当窥镜”的基础效果）
