做XR项目这些年，被问到最多的问题不是“角色怎么做移动”，而是“角色怎么放到该放的位置上”。普通Unity项目里设置角色位置和朝向，就是改transform.position和rotation两行代码的事；到了VR项目里，同样的需求要额外处理头显追踪、设备偏移、地面高度、传送结算，还动不动就冒出“传送完人埋地里”“转身后手柄乱飘”这种稀奇古怪的Bug。这篇文章就围绕Unity里设置VR角色位置和朝向这件事，从坐标系统原理讲到传送、转身的具体实现，再给一份我踩坑几年总结出来的问题排查清单。正在做VR交互、或者从普通3D开发转到XR方向的朋友，这篇可以直接当参考。

1. 先搞清楚VR里的“角色”到底是什么：定位问题不能只看一行代码

1.1 头显追踪决定了：Camera的位置是“只读”的

在Unity的XR项目里，场景结构一般是这样：根节点叫XR Origin（旧版本叫XRRig），它下面挂Camera Offset子节点，再往下才是主相机，左右手柄也是Camera Offset的子节点。这个层级不是随便设计的，它把“虚拟世界中的玩家锚点”和“真实世界中被追踪的设备”分开了。

• XR Origin：代表虚拟世界中玩家的位置和朝向，这个Transform你可以改，也应该由你的游戏逻辑来控制。
• Camera Offset：负责处理头显相对于人体或地面的偏移，大多数情况下你不用手动改。
• Main Camera：对应头显位置，每一帧由TrackedPoseDriver根据设备追踪数据写进去。

我习惯把XR Origin比喻成一条船的船体，头显是你站在甲板上的位置。你在船上走动（物理世界里移动头部、转身），甲板上的站位自然会变；但船本身开到哪里、船头朝向哪里，才是代码要控制的。对应到代码上，“设置角色位置”就是设置XR Origin的位置，“设置角色朝向”就是设置XR Origin的绕Y轴角度。

很多新人上来就爱干一件事：直接改Main Camera的transform.position，想把人放到某个点。结果要么发现下一帧相机被拉回去了，要么角色过去了、手留在原地。原因就是TrackedPoseDriver每个帧都在读取头显的六自由度数据，把相机位置和旋转强制覆盖成设备报告的数值。你改的那一下可能就存活了一帧，甚至一帧都撑不住。这不是引擎的Bug，而是VR的基本设定：相机的位姿必须服从设备追踪，否则玩家头部一动，画面就会撕裂。

正确做法是：移动、旋转都作用在XR Origin上，相机那一层不动。相机相对于Origin的偏移是现成的，直接拿来算传送目标点就行，这一点在后面会反复用到。

1.2 相机偏移量：搞懂“你在船上站的位置”

XROrigin组件上有一个很实用的属性：CameraInOriginSpacePos，返回主相机在Origin局部空间下的位置。说得直白点，它告诉代码“玩家脑袋相对于船体中心的偏差值”。

以地板追踪模式（Tracking Origin Mode = Floor）为例，Origin放在地板上，相机的高度大约是眼睛高度，也就是1.5到1.8米左右，XZ方向上基本接近0。但并不是每个人都站得那么正，有人习惯侧站一点、靠后一点，这个偏移量的X和Z就不为0。如果你不做任何处理，直接设置Origin.position等于目标点，玩家脑袋的实际位置会变成“目标点+头部偏移”，看起来就是整个人没站在目标点上。传送方案里必须把这个偏移减掉，不然每次传送完都差一截。

这一点也是不少多人VR社交应用里传送后站姿看起来奇怪的原因之一——头部偏移处理得不一致，传送参数又在多端传递，效果自然对不上。位置逻辑虽然只占整个项目代码量的一小块，但它直接影响玩家进入场景的第一感受，别在这种基础细节上省事。

2. 设置位置的两种主流方案：传送与平滑移动

2.1 传送：一套带偏移校正的正确打开方式

先说最原始、也最容易写错的版本。假设场景里有一个目标Transform，你想把玩家传送到那里，如果直接写：

// 错误示范 xrOrigin.transform.position = target.position;

多半会出现两种情况：要么玩家脑袋不在目标点上，要么传送后高度直接不对。原因就是上面说的偏移量没扣除，以及“目标点是脚底的位置还是头的位置”这件事没有定义清楚。

我推荐的写法是：先把目标点当作“玩家头部应该到达的位置”处理，然后扣除CameraInOriginSpacePos得到Origin坐标，再赋值。如果你希望目标点是“脚底位置”，比如射线命中的地面点，那可以直接赋值Origin.position，因为Origin本来就放在地面上，这时头和脚的语义天然一致。关键是项目里要统一语义，别一半用头部目标、一半用脚步目标，否则后面调Bug会调到怀疑人生。

完整传送函数参考：

using UnityEngine; using UnityEngine.XR.Interaction.Toolkit; public class SimpleTeleport : MonoBehaviour { [SerializeField] private XROrigin xrOrigin; [SerializeField] private CharacterController characterController; public void TeleportPlayer(Vector3 headTarget) { // 头部目标点 - 头部偏移 = Origin应处的位置 Vector3 headOffset = xrOrigin.CameraInOriginSpacePos; Vector3 originPos = headTarget - headOffset; // 传送过程中暂时禁用CharacterController，避免它把位置拽回去 if (characterController != null) { characterController.enabled = false; } xrOrigin.transform.position = originPos; if (characterController != null) { characterController.enabled = true; } } }

这里有一个关键操作：传送时把CharacterController先禁用，赋值后再启用。为什么？因为CharacterController身上挂着物理胶囊体，它的Move、碰撞检测，甚至引擎对它的自动位置同步，都可能在赋值之后把位置“纠正”回去。你手动改了Transform后立刻启用大概率没事，但不先禁用的话，内部对Controller的位置管理和你直接改的Transform会打架，表现就是传送到一半又弹回原位。这个坑我在项目里踩过不止一次，“禁用-赋值-启用”这套流程后来就成了固定动作。

注意：顺序不要颠倒。如果先赋值再禁用，引擎可能已经把位置同步出去了，等于白操作。

如果用的是XR Interaction Toolkit自带的TeleportationArea和TeleportationAnchor，可以省很多事：在地板上放TeleportationArea，给射线交互器配好Teleport交互模式，玩家瞄准、释放，TeleportationProvider会完成位置移动和朝向对齐，还自带预览指示器。内置方案已经处理了偏移和旋转，新手直接用非常稳。

但它也有局限：传送落点判定依赖射线命中collider，命中一个比较矮的桌子或斜坡，视觉效果就会很怪。所以我这边的策略是双轨并行：需要精确落点控制的场景（固定演出点位、任务引导点）用自己写的那套传送函数，地图漫游场景用内置TeleportationArea。两条路都走通之后，位置设置这块就基本不用再操心了。

2.2 平滑移动：别把位置当成“瞬移”来写

传送适合点对点移动，连续走路的场景还是需要平滑移动。XR Interaction Toolkit的ContinuousMoveProvider就是把摇杆输入映射成CharacterController.Move的位移，每帧累加。这里位置不再是“设置”出来的，而是“推动”出来的。它和传送的本质区别在于：传送直接改Transform，平滑移动每帧把位移塞给CharacterController，由物理系统决定最终落点。

自己写平滑移动也很简单，但有两个细节容易忽略。第一，移动方向要以相机朝向为准，而不是Origin.forward。玩家在现实中转身后，头显朝向变了，如果还用Origin.forward算方向，摇杆推前结果人往斜着走，头晕是轻的，撞墙才是常态。第二，重力必须处理，CharacterController自己不会自动落地，要手动累加垂直速度。

using UnityEngine; using UnityEngine.XR.Interaction.Toolkit; public class HeadRelativeMove : MonoBehaviour { [SerializeField] private XROrigin xrOrigin; [SerializeField] private CharacterController characterController; [SerializeField] private float moveSpeed = 1.5f; private float verticalVelocity; private const float gravity = -9.81f; // 外部注入摇杆输入 public Vector2 MoveInput { get; set; } private void Update() { if (characterController.isGrounded) { verticalVelocity = -0.5f; // 黏住地面，防止上下浮动 } else { verticalVelocity += gravity * Time.deltaTime; } Transform head = xrOrigin.Camera.transform; Vector3 forward = Vector3.ProjectOnPlane(head.forward, Vector3.up).normalized; Vector3 right = Vector3.ProjectOnPlane(head.right, Vector3.up).normalized; Vector3 move = (forward * MoveInput.y + right * MoveInput.x) * moveSpeed; move += Vector3.up * verticalVelocity; characterController.Move(move * Time.deltaTime); } }

注意CharacterController要放在XR Origin这个节点上，而不是放在Camera上，否则相机偏移和移动方向会互相干扰。XRI 2.x之后的版本里，CharacterController和XROrigin经常一起出现在同一个GameObject上，两套系统靠LocomotionProvider协调。如果你自己手动实现了移动，记得别让XRI自带的ContinuousMoveProvider同时生效，否则两个系统都在推同一个Controller，角色就像抽风一样来回抖。

3. 朝向设置：转身这个动作比想象中讲究

3.1 SnapTurn和ContinuousTurn：转的都是Origin

设置朝向本质上就是设置XR Origin的旋转，但绕Y轴的角度是有讲究的。玩家物理转身时，头显追踪直接改变相机的世界旋转，这个不需要代码管；代码要管的，是虚拟世界中角色的面朝方向。

最直觉的错误做法是改相机的rotation，比如：

// 错误示范 camera.transform.rotation = Quaternion.Euler(0, 90f, 0);

下一帧TrackedPoseDriver会把相机旋转覆盖回设备报告的方向。就算你能让相机固定住，手柄、身体、射线指示器这些子物体也不会跟着转，整个世界就散了。

正确的转法在XR Origin上下手。瞬转（SnapTurn）就是每按一次按钮转一个固定角度，一般取值在30度到45度之间：

public void SnapTurn(float angleDegrees) { xrOrigin.transform.Rotate(0f, angleDegrees, 0f, Space.World); }

平滑转身（ContinuousTurn）则是按住按钮期间持续加角度：

public void SmoothTurn(float degreesPerSecond, float deltaTime) { xrOrigin.transform.Rotate(0f, degreesPerSecond * deltaTime, 0f, Space.World); }

XR Interaction Toolkit也原生提供了SnapTurnProvider和ContinuousTurnProvider，直接在Inspector里配按钮和角度数值，内部逻辑和上面这两段代码本质上一样。自己写一遍的好处是能看清楚它到底做了什么，理解了之后就放心用内置组件了。

我见过有人为了“精确控制转身速度”自己写旋转，结果把旋转同时应用到了Origin和Camera上，导致玩家一转就头晕到想吐。记住总原则：虚拟世界里所有由代码产生的位移和转身，都发生在XR Origin这个锚点上；相机那一层的姿态，永远交给设备追踪。

传送锚点也能携带旋转信息。TeleportationAnchor的Transform.rotation代表目标朝向，传送完成后玩家会被对齐到那个朝向。做演出点位、任务引导点的时候这个功能特别好用：把箭头转到想要的方向，玩家落地自然朝那边看。

3.2 转身引发的两大问题：视觉眩晕和相机画圈

转身最容易引发晕动症，原理不复杂：玩家的内耳说自己没动，但眼睛看到整个场景在转，大脑处理不过来，于是胃开始抗议。解决办法有两条路：物理层面选瞬转，视觉层面做遮罩。

瞬转因为画面在极短时间内切换，大脑来不及产生“正在移动”的错觉，晕动症的概率远低于平滑转身，这就是主流VR游戏默认都做SnapTurn的原因。如果项目实在要做平滑转身，记得加TunnelingVignette，也就是隧道式遮罩：转动时屏幕四周的视野收窄、中央保留一个可视圆，视觉上减少“我在转”的感知。XR Interaction Toolkit示例工程里就带这个组件，挂在相机父节点下，平时透明度为0，转身时根据转速动态调整遮罩范围。具体参数建议找几个不同耐受度的人现场试，没有统一标准。

另一个问题叫“相机画圈”。旋转Origin时，如果相机在Origin局部坐标下的偏移不为零，比如玩家实际站在房间的偏左位置，那么旋转会让相机绕着Origin的轴线画一段弧线。玩家视野里看到的不是原地转，而是整个人被“甩”出去一下再回来。房间规模场地里，这个现象会特别明显。我的处理经验是：旋转前记录相机在Origin局部空间的偏移，如果XZ偏移量明显，就把Origin的旋转中心临时挪到相机投影点上，旋转结束后再挪回来。不过大多数项目的偏移其实很小，玩家对弧线并不敏感，所以不必为一个极端情况写复杂算法，知道成因、能解释、能定位就可以了。

4. 高频问题排查与API演进：现场踩坑实录

4.1 传送后人埋地里或飘半空：高度语义混了

这类问题十有八九是“目标点”和“Origin位置”的高度语义没统一。前面已经说过：目标点是头部语义，要减去CameraInOriginSpacePos；目标点是脚步地面点，可以直接赋值Origin位置。混用之后，轻则偏高半米，重则直接卡进地面。

另外还要留意追踪原点模式。OpenXR里有Device和Floor两种追踪原点：Device模式下，Origin的零点在头显初始位置，人会被整体抬高；Floor模式下，Origin零点在地面，需要系统提供地面高度。XROrigin上通常要显式请求Floor模式，否则有些设备默认Device模式，高度永远不对。

我通常会写一个校准函数，在应用启动和玩家切换站位后调用：

using UnityEngine.XR; public static class TrackingCalibration { public static void Recenter() { // 获取当前有效的XRInputSubsystem后调用TryRecenter() // 各平台SDK对“重新居中”的接口叫法不同，但目的都是重置当前姿态零点 XRInputSubsystem subsystem = null; subsystem?.TryRecenter(); } }

各平台SDK对“重新居中”接口的叫法不同，有的叫Recenter，有的叫Reset，但方向一致：让设备重新定义当前头姿为零点。玩家站定后按一下校准键，位置朝向就归零了。这个功能是VR项目的基础设施，建议从第一天就做进游戏里。

4.2 转身后手柄错位：大概率旋转了不该转的节点

如果你发现旋转以后，左右手柄跑到身体侧面去了，或者射线指示器和手柄朝向不一致，基本可以断定旋转应用错了对象。打开Hierarchy检查一下，看旋转是作用在XR Origin上，还是作用在Camera或Camera Offset上。前者表现为手柄跟着转，后者表现为相机转了但手柄留在原地。

修法很简单：把多余的旋转去掉，只在Origin做转向。如果确实需要转Camera Offset，比如做坐姿模式调整，那就要同步旋转所有子节点，包括手柄和追踪器，手一抖就会漏一两个。总之一句话：旋转要打在锚点上，不要打在子节点上。

4.3 XRRig与XROrigin的版本差异

在XR Interaction Toolkit 2.0之前，玩家锚点组件叫XRRig；2.0之后改叫XROrigin，同时多了CameraInOriginSpacePos、CameraFloorOffsetObject这些命名清晰的属性。老代码迁移时最常踩的坑，是把rig.cameraGameObject.transform.localPosition当偏移来用，新版本要换成xrOrigin.CameraInOriginSpacePos。

老代码大概长这样：

XRRig rig; Vector3 offset = rig.cameraGameObject.transform.localPosition; rig.transform.position = target - offset;

新版本改成：

XROrigin origin; Vector3 offset = origin.CameraInOriginSpacePos; origin.transform.position = target - offset;

看起来差别不大，但前提是你得先确认项目用的XRI版本。我的经验是：与其在多个老版本之间做兼容，不如统一升级到2.x，新API稳定且持续维护。网上很多教程默认是老API，直接复制粘贴会报一堆错误，别问我怎么知道的。

4.4 多人联机时位置同步的坑

联机项目里，同步的是XR Origin节点的Transform，而不是相机。原因还是那个：相机位置每帧被设备覆盖，同步相机等于同步噪声。正确做法是服务器上只同步Origin的位置和Y轴旋转，把相机偏移留给客户端本地计算。同时还要处理传送预测和插值，否则A玩家看到B玩家传送像切片一样一顿一顿的。

这部分展开可以单独写一篇，这里提两个关键点。第一，位置同步频率建议20到30Hz，太高带宽撑不住、太低轨道漂移明显。第二，所有玩家必须处于同一个追踪原点模式下，Floor和Device不一致，会导致两个人看到的对方高度差一截。联调时如果发现“他在地板下面”，先查追踪模式，再查同步代码，不要一上来就怀疑网络库。

4.5 常见问题速查表

5. 实操心得：几个文档里不会写、但实战救命的细节

5.1 好用的“传送落点校验”

无论用内置TeleportationArea还是自己写传送，都应该把“传送目标点是否安全”单独抽出来。我习惯在目标GameObject上加一个标记组件，里面配置三件事：传送后的玩家朝向、是否保留当前高度、是否允许这个点被多人重复使用。传送函数在赋值前先做校验，不过就回抛一个事件。这套设计在项目后期特别有用，做演出点位排序、任务关卡切换的时候，不会因为一个空引用崩溃在线上，也方便策划在编辑器里直接配置点位。

5.2 开发模式下的调试快捷键

我在开发版本里固定留一组只属于调试的快捷逻辑：按住左摇杆下加菜单键，原地重置角度；双击右侧按钮，传送回出生点；长按某个组合键，把当前玩家位置保存到文件。这些在正式版里全部隐藏或移除，但开发期能省掉大量反复进出场景的时间。VR里没有方便看的控制台界面，调试信息越直接越好。

另外我一直建议团队保留一个“假HMD”调试模式：Editor里用一个可拖动的场景对象模拟头显轨迹，方便在没有真机的情况下验证传送、碰撞、移动方向之类的逻辑。注意这只是逻辑验证，画面最终效果必须真机上看，两者的差距还是很大的。

5.3 出场前必须做的真机验收清单

最后给一份真机验收清单，覆盖位置和朝向相关的核心场景：

• 从房间角落传送到房间中央，确认左右偏移量在可接受范围内
• 站姿和坐姿各测一遍，确认高度语义在两种状态下都正确
• 连续做10次SnapTurn，确认没有累积的角度漂移
• 在接近墙的位置触发传送，确认没有嵌入碰撞体
• 拿着手柄做一次完整转身，确认手柄和相机没有脱节
• 多人模式下两个玩家互看，确认对方高度和朝向一致

我在实际项目里反复验证过一件事：位置和朝向的逻辑占整个VR项目的代码量可能不到5%，但它决定了玩家进入场景后的第一感受。传送准不准、转身晕不晕，比很多花哨的特效更能决定一个VR应用的口碑。把这块基础打扎实，后面再加什么交互都不会慌。