输入与移动

XR 里的输入不是事件。没有 click，没有 keydown，指针底下也没有元素。每一帧你拿到的是一组输入源，各自带着姿态、类手柄的按键状态，可能还有一副 25 关节的手部骨架，而这些**意味着什么**，得你自己决定。捏合、抓取、指针射线、传送弧线：这些在 API 里一个都不存在，它们都是你从姿态里搭出来的。

这里三篇从具体走向有争议。手柄那篇最机械：输入源、几乎人人会栽一次的 targetRay 与 grip 之分、按键与轴的状态、还有触觉反馈。手部追踪把按键换成了几何 —— 同一套输入模型，但手势变成了两个关节之间的距离，加上一个**由你来定**的阈值。移动那篇则没有正确答案，因为约束根本不是技术性的。

最后那篇正是这一区要成组存在的理由。XR 里每一个输入决定，最终都会撞上身体：射线比手更好瞄准但没那么直接；一个你觉得干脆利落的捏合阈值，在别人手上就是一次次抓空；而拍视频最好看的平滑移动，恰恰是会让一部分用户不得不坐下的那一种。API 给你的是姿态，**舒适度是一个你没法从规范里读出来的设计问题**。

本区包含

1. 01VR 控制器控制器到你手里时是一个 XRInputSource：两个各自独立的空间、一个可有可无的 gamepad，以及一个在所有设备上行为一致的 select 事件 —— 包括那些根本没有控制器的设备。
2. 02手部追踪一只被追踪的手以 XRHand 的形式到达代码里：25 个具名关节，每个都有自己的位姿、朝向和半径 —— 而且每一个都允许在任何一帧缺席。
3. 03移动与舒适度在 WebXR 里你永远不移动相机。你把参考空间换成它自己的一份偏移副本 —— 而这件事是瞬间完成还是逐渐完成，决定了这个应用是舒适还是催吐。

按这个顺序读

手柄确立了输入源模型：一帧如何把设备、姿态和按键状态交给你。手部追踪默认你已经有了这套模型，只是把按键换成了骨架。

移动**刻意**放在最后。它同时依赖前两篇，还依赖一个前两篇都不需要的判断：你愿意对一个其实没在动的人，施加多少运动。