Unity坐标归零却不在原点？一文读懂本地坐标与世界坐标

1. 先看清现象：Inspector 里重置的 Position，本来就不是世界坐标

1.1 一个五分钟就能复现的实验

打开 Unity 新建一个场景，创建一个 Capsule（或者任一基础几何体），在旁边再创建一个空物体 Cube 当"父节点"。注意不是并列关系，而是真正的父子挂接：把 Capsule 拖到 Cube 下面，或者用代码 Parenting。

然后把 Capsule 的 Transform Position 三个输入框全部改成 0，Rotation 改成 0，Scale 改成 1。到这一步，很多人的想法是"我已经把坐标重置了"。但实际渲染出来的 Capsule 依然停在场景里的某个位置，并没有回到世界原点 (0,0,0)。

更反直觉的是：你如果把 Cube 父节点随便挪到别处，Capsule 也会跟着动——尽管它的 Position 面板上依然写着 (0,0,0)。也就是说，这个 (0,0,0) 并没有让 Capsule"扎根"在某一个固定的绝对位置。这个现象，就是理解整个问题的第一把钥匙。

1.2 Local Position 和 World Position：两个被混为一谈的概念

Unity 的 Inspector 上显示的 Position，是 Local Position——本地坐标，意思是"我相对于父节点 Transform 原点的偏移量"。Local Position = (0,0,0) 的真正含义是"我紧紧贴在父亲的原点上，父亲在哪我就在哪"，而不是"我站在世界原点"。

而 World Position（世界坐标）是引擎在运行时通过一连串矩阵变换实时算出来的结果。Inspector 默认不显示它（可以切 Debug 模式，或者选中对象后看 Scene 视图里 Transform Gizmo 的数值）。世界坐标等于"从物体自身出发，沿着父亲的父亲……一直追溯到场景根节点"这一整条链累计出来的最终位置。

这个理解一旦建立起来，标题里的问题就回答了一半：不是引擎坏了，不是坐标被重置失败，而是你重置的是"本地坐标里的数字"，它和"世界坐标里的原点"根本没有直接对应关系。

1.3 为什么会"归零后仍然不在原点"——一句话版答案

一句话版答案：子节点的本地坐标归零，只是让子节点移动到父节点的原点，而不是世界原点。如果父节点不在世界原点，你的 player 自然就不在原点。

但你也别急着关页面。父节点位置只是最表层的原因，往下挖还有三个非常隐蔽的偏移来源，以及一套完整的解决思路。这些才是真正会消耗你半天时间的地方，我放在后面章节细讲。

2. 坐标是整条父子链的"换算结果"：矩阵连乘里的几个关键角色

2.1 从根节点到子节点，引擎其实做了连续变换

任何一个带 Transform 的物体，内部都保存着两类数据：自己的 Local Position / Local Rotation / Local Scale（相对于父节点），以及指向父节点的引用。引擎要渲染一个物体时，会沿着父子链做矩阵连乘。

假设 player 的父节点是 A，A 的父节点是 B，那么 player 在世界空间里的变换矩阵大致是：

worldMatrix(player) = 平移(player) × 旋转(player) × 缩放(player) × 平移(A) × 旋转(A) × 缩放(A) × 平移(B) × 旋转(B) × 缩放(B) × ……

这里每个"×"都代表一次坐标系的叠加。要点是：最终位置是整条链上所有变换叠加的结果，不是某一个数值单独决定的。这也是为什么"只看最底层对象的 Position"永远无法判断它在世界空间里的真实状态。

用生活化类比：你在高铁上站起来向前走两米，你相对于车厢移动了 2 米，但相对于地面你可能已经移动了 2 公里。你的"本地坐标"（在车厢里的位置）很干净，但"世界坐标"（相对于地面）取决于车厢本身开到了哪里。player 就是车厢里的乘客，(0,0,0) 只表示"我在车厢正中央"，绝不等于"我在地球原点"。

2.2 重置为 0 的那一刻，引擎到底做了什么

当你把 Position 改成 (0,0,0)，引擎做的事是：把 player 的本地偏移清零，让 player 的 Transform 原点与父节点 A 的 Transform 原点重合。也就是说，player 会瞬移到父节点 A 的"身体中心"（更准确说是 A 的坐标原点）。

所以，如果父节点 A 在世界空间里位于 (100, 20, -5)，你重置本地坐标后，player 的世界坐标就变成 (100, 20, -5)，而不是 (0,0,0)。这就是"即便重置坐标但坐标并非原点"的最直接解释。

2.3 同一套逻辑也贯穿在 ROS tf、3D 建模软件里

这套"父变换 × 子变换"的链式思维，并不只属于游戏引擎。搞过机器人的朋友应该很熟悉 ROS 里的 tf 树，每个坐标系之间的变换关系就是一张父子链，机器人末端执行器的位置必须从 base_link 一路累乘到 tool0 才算得出来。Blender、Maya 里也有父子级和骨架层级，道理完全一致。

所以当你真正理解了"本地坐标永远相对于父亲"这一点，以后不管碰到 Unity、Godot、Unreal，还是任何带层级结构的 3D 工具，都能一眼看穿这类问题的本质，而不是每次遇到都要从头排查一遍。

3. 除了父节点偏移，还有三个隐藏的"坐标污染源"

3.1 父节点的旋转和缩放：零位置会被"扭曲"

如果父节点 A 不仅移动了，还带着旋转和缩放，问题就会更隐蔽。子节点的 Position 全为 0，看起来"已经归零"，但父级的旋转矩阵和缩放矩阵照样参与连乘，于是子节点映射到世界空间的结果，不是简单平移，而是先被拉伸、再被旋转、最后再加偏移。

举个例子：一个大平台，父节点绕 X 轴旋转了 90 度。你把 player 挂上去并把 Position 归零，player 就会"躺"下来贴在平台面上，看起来像是被压扁了。如果不理解旋转链的存在，你会以为是 Scale 出了毛病，其实只是父级的 Rotation 叠加进来了。

最坑的是父节点带非等比缩放（比如 Scale = (3, 1, 1)）。这种情况下子节点的世界坐标映射会产生剪切变形，子物体旋转之后甚至会出现平行四边形那样的扭曲效果。这类问题用眼睛很难判断，必须逐步断链才能定位，是排查坐标问题时最"费眼神"的一类。

3.2 模型 Pivot 和 Transform 原点：原点不等于视觉中心

另一个非常常见的偏移来源，是模型本身的枢轴点（Pivot）。Transform 位置 (0,0,0) 表示的是 Transform 原点，而不是模型的几何中心。很多美术资源导出时，网格顶点并不是围绕原点对称分布——角色模型的原点可能在脚底，一把枪的原点可能在枪口或握把处，资源商店下载的模型更是千奇百怪。

所以即便父节点正好在世界原点，且没有旋转缩放，你挂上 player 并把 Position 设为 0，模型的网格也未必"站"在原点——可能是脚底压着原点，也可能是脑袋顶着原点。严格来说，这不算"坐标没回到原点"，而是"你想要的视觉参照点（模型中心或脚底）和你控制的 Transform 原点不是同一个点"。

在 Unity 里，可以在 Edit → Project Settings → Editor 里把 Inspector 的 Pivot 显示方式调整成模型中心；也可以在模型导入设置里处理 Pivot；更通用的做法是外包一层空物体，手动调整子级偏移，把模型的视觉中心挪到 Transform 原点上。这个基础整理工作建议尽早做，后面做动画、做瞄准、做挂点都会受益，否则每次挂接都要额外补偿一段偏移。

3.3 Collider 与逻辑区域偏移：看起来在原点，判定却不在

还有一类非常隐蔽的问题：Transform 原点确实在原点，但 Box Collider / Sphere Collider 的 Center 设成了别的值，或者 Mesh Collider 用的是一套偏移网格。结果就是：视觉上 player 站在原点，物理上它的碰撞盒却悬在半空，或者陷进地板一截。

我为什么把 Collider 也拉进来？因为在实战排查里，真有开发者说"坐标已经重置，但 player 在场景里的表现位置不对"，翻来覆去查了半天，最后问题是 Collider 的 Center。所以遇到"坐标归零但实际行为怪异"的情况，请把 Collider 的 Center / Size 也检查一遍，尤其是做需要和地面精确接触的角色时，这个检查不能省。

4. 把 player 真正放到世界原点：四种可复制的做法

先放一张速查表，方便你按场景直接对号入座：

4.1 方案 A：先脱离父级、设置世界坐标、再挂回去

如果你就是想顺顺利利地让 player 出现在世界原点，请分两步走。

第一步，先把 player 从父节点下面拖出来，让它成为场景根级物体（层级面板最顶层）。此时 Inspector 显示的 Position 就是世界坐标，把它设为 (0,0,0)。这时候 player 就在世界原点了。

第二步，准备挂接。在挂接之前，先看一眼父节点 A 的世界坐标是多少。假设 A 的世界坐标是 (10, 5, 0)，那么把 player 的本地 Position 改成 (-10, -5, 0)，再拖回 A 下面。挂接完成的那一刻，player 的本地坐标是 (-10, -5, 0)，加上父级的世界偏移 (10, 5, 0)，刚好等于世界原点。

这个方法完全手算，适合没有脚本依赖的纯编辑期操作。缺点是如果父节点层级很深、旋转又复杂，手工推算很容易出错，那就直接上方案 B。

4.2 方案 B：SetParent 的 worldPositionStays 参数是关键

用代码做挂接时，Unity 的 SetParent 有一个第二参数 worldPositionStays，它决定挂接前后子节点的世界坐标是否保持不变。

// 挂到 parent 下，同时保持世界坐标不变（推荐） player.transform.SetParent(parentTransform, true); // 挂接后强制把世界坐标设为原点 player.transform.position = Vector3.zero;

第一行执行完，player 的世界坐标和挂接前一模一样，父级只是换了，不会跳变；第二行执行完，player 被强制拉到世界原点。这两行组合起来，就是一个"挂接后仍精确出现在原点"的可靠实现。

这里我特别提一下 worldPositionStays 的默认值：是 true，不是很多人以为的 false。所以你不传第二参数时，挂接前后世界坐标保持不变。反之，如果你传 false，挂接后本地坐标保持不变、世界坐标会跟着父级跳变——这就是很多"一挂上去就消失/飞走"事故的来源。

4.3 方案 C：用 InverseTransformPoint 把世界目标换算成本地偏移

实战里更常见的需求不是"丢到世界原点"，而是"丢到世界空间某个指定点"，比如剧情触发点、存档点、出生点。这时候不要手工换算，直接让引擎帮你算逆变换：

// worldTarget 是世界空间里的目标位置 Vector3 localPos = parentTransform.InverseTransformPoint(worldTarget); player.transform.localPosition = localPos;

InverseTransformPoint 的作用，是把一个世界坐标反向转换到父节点的本地坐标系里。它相当于引擎帮你完成"车厢里的哪个座位，才能让我在地面上正好踩到目标点"的全部计算，父级的平移、旋转、缩放全部包含在内。这个方法比你手推矩阵可靠得多，强烈建议当成默认姿势。

4.4 方案 D：中间锚点解耦"跟随"和"定位"

如果你的需求是"player 必须一直挂在某个移动平台 / 相机节点下面"，又要让它在世界空间里有精确的位置，直接挂接往往两头都顾不好。我的做法是引入一个中间锚点：

先在场景原点创建一个空物体 Anchor，player 挂到 Anchor 下，本地 Position 设为 0。然后写一小段代码，让 Anchor 的世界位置逐帧等于移动平台/相机节点的世界位置。这样 player 的层级仍然是"挂在目标物体下"的，跟随性不变；同时因为 Anchor 被强行锚定到目标位置，player 在世界空间里的位置完全可控，localPosition 也可以随时调整而不被父级旋转缩放干扰。

别小看这个"中间锚点"思路。做震屏、载具跟随、武器挂点、角色挂背包这类需要"既要严格跟随、又要精确对齐"的场景，它几乎是最通用的解。直接用父子挂接，本地坐标会被父级"绑架"；中间锚点则是把"跟随"和"定位"两个需求拆开，各自解决。

4.5 Godot 版本的对应操作

Godot 里对应的概念是 global_position / global_transform。重置本地坐标后，子节点的实际渲染位置同样是父级坐标系映射的结果。想放到世界原点：

# Godot GDScript player.global_position = Vector3.ZERO # 或者保留跟随行为，只对齐世界位置： player.global_transform.origin = Vector3.ZERO

Godot 里更常遇到的其实是 2D 场景的锚点问题：一个 Sprite2D 挂到另一个节点下，Position = (0,0)，它在屏幕上的位置等于父节点的 global_position，而不是屏幕左上角原点。这个和 Unity 3D 的问题本质上是同一个坐标空间概念——只是换了个引擎、换了个维度，底层逻辑一模一样。

5. 这类坐标问题在实战中伪装成的三种"怪现象"

5.1 相机挂点与震屏时的瞬间漂移

最常见的现场发生在相机跟随。你想让相机跟随炮塔旋转，就把 Camera 挂到炮塔下，顺手把 Position 归零。结果相机没有移到角色头部，而是瞬间飞到了炮塔的 Transform 原点。这时候正确的做法是：先把相机摆到正确的世界位置，再挂接，并且 SetParent 的第二参数传 true（保持世界坐标）。之后再想做震屏，再单独用 localPosition 加偏移，这样震屏只会影响本地坐标，不会把相机的世界位置带"跑偏"。

5.2 存档读档后位置莫名错乱

很多项目用 PlayerPrefs 或 JSON 存档时，习惯直接存 player.transform.position。但如果存的时候 player 是某个父节点的子物体，你存进去的其实是"当时的世界坐标"；读档时引擎把它赋值给本地坐标，或者恢复层级顺序不一致，读出来的位置就会差一截，甚至跑到场景外面。

我的经验是：存档一律存世界坐标，读档时先确保层级关系已经恢复完整，再通过 transform.position（引擎赋值时会自动把世界坐标转换成本地坐标）去设置。只要层级关系到位，这个世界坐标赋值就是稳定的。千万不要存 localPosition，一旦后期调整过父级位置，所有旧存档直接作废。

5.3 多层嵌套后的位置"雪崩"

一个物体套一层父级没什么，层层嵌套五层之后，每一层都有一点旋转和偏移，最终叠加下来位置就完全不可控。这其实就是矩阵连乘的累积效应：每一层变换都对下层子节点施加一次新的坐标系变化，多层叠加之后，单纯靠把最底层坐标清零根本救不回来。

排查这类问题时，不要一层层盯着 Inspector 猜。最高效的手段是写一个临时脚本，运行时打印每一级的 localPosition 和 worldPosition，逐级对照，先找到"哪一层开始和你预期不符"，再决定是断链还是补偏移。如果时间紧，也可以直接把中间层级全部断开，先把最底层物体放到世界原点，再一层层挂回去，每挂一层验证一次位置，这个方法实测最省心。

6. 我自己的排查习惯和几条实用建议

处理这类坐标问题多了，我慢慢养成了几个固定动作，分享出来也许能帮你少走弯路。

第一，永远把坐标分成"本地"和"世界"两套思维。任何层级未理顺的节点，直接看面板数值下结论都很危险。你要判断一个物体的真实位置，优先看 Scene 视图里的 Gizmo 数值，或者拉一个代码片段打印 transform.position（注意，transform.position 在 Unity 里永远是世界坐标，localPosition 才是本地坐标，这个区分要刻在脑子里）。

第二，做挂接之前先问自己：我要的是"跟着父级走"还是"固定在世界某点"。前者用本地坐标调整相对偏移，后者用世界坐标直接赋值。需求不对，做法就全错，这个问题在动手之前花十秒想清楚，能省后面半小时。

第三，重置坐标前，先看一眼父节点的 World Position 是多少。这个动作能让你瞬间判断"归零后大概会出现在哪儿"，是排查这类问题最快的捷径。你甚至可以在心里先算一遍：子节点本地归零后的世界位置，必然等于父节点的世界位置——除非还有旋转缩放和 Pivot 的干扰。

第四，中间锚点真的是万能药。新建空物体做锚点/中间层，成本几乎为零，却能同时解决"跟随"和"精确对齐"两个互相矛盾的需求。我见过不少团队在复杂层级里反复调坐标调到崩溃，最后引入一个 Anchor 空物体，十分钟收工。

第五，别忽视模型 Pivot 和 Collider 偏移。如果所有矩阵计算都对，画面表现还是不对，那问题多半出在模型的"原点在哪里"以及"判定体积在哪里"。这两样东西不属于 Transform，但直接影响你看到的结果，很多"坐标玄学"最后都会查到它们头上。

最后再啰嗦一句：这套逻辑在 Godot、Unreal、Blender、Maya 里完全一样，一切父子挂接都会引入一个相对坐标系，(0,0,0) 永远只是"相对父节点原点"，而不是"相对世界原点"。想清楚"我相对谁为零"，比背一百个 API 都管用。等你真正把这条链想透了，以后再看到"坐标归零却不在原点"，你就会和我一样，不再怀疑人生，而是会心一笑，顺手打开父节点的 Transform 面板。