第一次遇到空间错位时我把问题归咎于“头显漂移”。房间没有动定位边界也正常但虚拟桌子每次启动都会顺时针偏一点站在入口处看只差几厘米走到房间另一端误差已经足以让手柄穿过桌沿。真正的问题并不在追踪精度而在我把三个不同的坐标系当成了一个。这类故障麻烦之处在于它看起来很像随机漂移实际上往往是稳定的系统误差。只要把坐标链拆开、用地面上的三个点做一次可复现标定就能判断到底是原点、朝向、比例还是运行时参考空间出了问题。下面记录一套不绑定设备型号的做法。它适合展厅、教室、门店和小型大空间体验也适合在 WebXR 原型阶段快速定位“为什么越走越歪”。一、先别调参数错位通常有四种形状我会先让测试者依次站到房间中央和四个角不动任何配置只记录虚拟标记相对地面胶带的位置。误差的形状比误差的绝对值更有信息量。现象更可能的原因第一检查项所有位置都朝同一方向偏移偏差近似相等平移量错误房间原点是否取错离原点越远横向误差越大航向角错误“正前方”基准线是否可靠X、Z 两个方向误差都按距离同比增长单位或比例错误是否把厘米当成米本次正常、重启后整体换了位置参考空间重建是否错误持久化了运行时原点最容易误判的是第二种。假设朝向只错了 1°在距原点 4 米的位置横向误差约为4 × sin(1°) ≈ 0.07 米也就是 7 厘米。入口附近很难察觉房间尽头却已经明显错位。因此“中央点对齐”不能证明空间已经标定正确。二、坐标链不要把 XR 原点当成房间原点WebXR 的位姿来自某个XRReferenceSpace。常见运行时以米为单位、Y 轴向上观察方向沿 -Z但local-floor的原点由运行时建立并不等于施工图中的房间原点也不保证设备重启后仍对应同一块地砖。应用真正需要的是这条变换链世界坐标 房间到世界的变换 × XR 到房间的标定变换 × XR 位姿其中XR 位姿由每一帧的XRFrame提供XR 到房间的变换由现场标定得到房间到世界的变换由内容设计决定例如把真实墙面映射到虚拟展墙。把三者揉成一个“magic offset”虽然能暂时对齐某个点但之后很难判断究竟是哪一层失效。三、用三个地面点完成一次可验证标定我在地面贴三个可重复找到的标记A房间原点B从 A 指向房间定义的“正前方”C位于侧边只用于校验不参与第一次拟合。A 与 B 的距离尽量拉长。两点只相距 50 厘米时1 厘米的落点误差会带来约 1.15° 的角度误差两点相距 3 米时同样的落点误差只对应约 0.19°。这比不断调小数点后的旋转参数有效得多。标定流程如下请求local-floor参考空间如果设备不支持再明确降级而不是悄悄混用local。让控制器或头显中的准星依次对准 A、B采集各 30 帧。对每组位置取中位数减少手部抖动和偶发跳点的影响。用 A 求平移用 A→B 求水平面内的航向角。把 C 代入变换只计算残差残差过大就拒绝保存本次标定。这里刻意不让 C 参与第一次拟合。原因很简单如果三个点都拿来“追着数据拟合”一个贴歪的胶带也可能得到看似漂亮的结果保留一个独立校验点才能暴露采集错误。四、核心代码只解平移和航向角对于地面平整的小空间先解四自由度——X、Y、Z 平移加水平航向角——通常比直接上完整的六自由度矩阵更稳。下面的代码省略 UI只保留计算部分。const median (values) { const sorted [...values].sort((a, b) a - b); const mid Math.floor(sorted.length / 2); return sorted.length % 2 ? sorted[mid] : (sorted[mid - 1] sorted[mid]) / 2; }; const medianPoint (samples) ({ x: median(samples.map((p) p.x)), y: median(samples.map((p) p.y)), z: median(samples.map((p) p.z)), }); const horizontalAngle (from, to) Math.atan2(to.x - from.x, -(to.z - from.z)); export function solveRoomCalibration({ xrA, xrB, roomA, roomB }) { const xrYaw horizontalAngle(xrA, xrB); const roomYaw horizontalAngle(roomA, roomB); const yaw roomYaw - xrYaw; const cos Math.cos(yaw); const sin Math.sin(yaw); const rotatedA { x: xrA.x * cos - xrA.z * sin, y: xrA.y, z: xrA.x * sin xrA.z * cos, }; return { yaw, translation: { x: roomA.x - rotatedA.x, y: roomA.y - rotatedA.y, z: roomA.z - rotatedA.z, }, }; } export function applyCalibration(point, calibration) { const { yaw, translation: t } calibration; const cos Math.cos(yaw); const sin Math.sin(yaw); return { x: point.x * cos - point.z * sin t.x, y: point.y t.y, z: point.x * sin point.z * cos t.z, }; }实际项目里我还会把以下信息和结果一起保存参考空间类型、标定版本、采集时间、A—B 实测距离、校验点残差。不要保存 Cookie、账号或设备序列号这些信息对复现坐标问题没有帮助。五、一个小数据集足以识别大多数错误以下数字是为了说明方法而构造的示例不是某款设备的性能测试。房间坐标中A 为(0, 0, 0)B 为(0, 0, -3)C 为(2, 0, -2)。检查项标定前标定后示例判定A 点平面误差11.4 cm0.8 cm通过B 点平面误差15.2 cm1.6 cm通过C 点平面误差18.7 cm2.4 cm预警但可继续A—B 距离差0.9%0.9%不应由刚体变换“修复”如果平移和旋转完成后A、B 对齐而 C 仍偏差很大需要检查的不是更多旋转参数而是下面三件事物理测量是否准确XR 运行时是否存在边界重建或短时追踪丢失内容资产是否在导出时发生了单位缩放。刚体变换不能修复比例错误。试图给空间偷偷乘一个0.98很可能让当前三个点更好看却让虚拟物体尺寸失真。六、验收不要只看“能不能对上”我的验收表会固定测试路径而不是让体验者随便走一圈冷启动应用在 A、B、C 三点各停留 5 秒沿房间边缘完整走一圈再回到 A摘下并重新戴上头显复查三点完全退出会话后重进确认系统要求重新标定或正确恢复遮挡部分追踪视野 2 秒恢复后观察是否出现整体跳变。阈值必须结合设备、场地和交互风险制定。对只展示信息的空间5 厘米可能可接受如果虚拟按钮需要贴合真实台面2 厘米也可能太宽松。关键不是照搬某个数字而是提前定义“超过多少必须阻止进入体验”。我通常采用三档结果通过所有校验点都在目标阈值内可用但需复核没有越过安全阈值但出现趋势性误差失败越过安全阈值、参考空间改变或数据不足。“失败”必须让用户知道下一步做什么例如“请重新对准 A、B 两点”而不是只弹出一句“标定异常”。七、最后得到的不是一组参数而是一条证据链空间标定最有价值的改进不是把偏移从 7 厘米调到 2 厘米而是把问题从“感觉有点歪”变成可定位、可复测的工程对象误差是否随距离增长重启后是参数失效还是参考空间被重建第三个点能否独立验证前两个点算出的变换本次结果是否达到场景自己的安全阈值当这些问题都有记录时换头显、换房间或换内容资产都不需要从“再试着转一点”重新开始。房间确实没有动。真正需要固定下来的是房间、运行时和虚拟世界之间那条清楚的坐标链。