企业官网建设流程全解析

如果你和我一样，第一次照着教程写完第三人称控制角色移动的代码，按下 WASD 那一刻，角色确实是动了，但总有一股说不出的别扭：转向像穿着冰刀在滑，松手之后还要漂出去半米，镜头一晃就分不清东南西北。这个功能在 Unity 里之所以被很多人叫做"易上手、难调好"，是因为它真正的门槛从来不在"怎么让角色位移"，而在"怎么让移动这件事符合人脑的预期"。本文想聊的就是这后半件事：第三人称移动的控制方案选型、相机跟随、输入方向转换、手感参数调优，以及我踩过的一系列坑，希望能给正在被"角色像在溜冰"折磨的开发者一些参考。

1. 动手之前，先把"移动手感"这个词拆开再写代码

很多刚接触第三人称的开发者会直接搜"角色移动脚本"，拿到一段transform.Translate或CharacterController.Move的代码就往上贴，但贴完之后发现手感不对，又不知道该调哪里。这不是代码的问题，而是我们一开始就把"移动"理解成了一个数学问题：输入方向乘以速度，然后让角色位置发生变化。实际上，对玩家来说，"移动手感"由三个完全不同的东西共同组成。

1.1 大多数教程省略的部分：为什么直接改位置会"滑"

我在帮 A 同学调试一个 Demo 的时候，他贴给我的代码长这样：

void Update() { float horizontal = Input.GetAxis("Horizontal"); float vertical = Input.GetAxis("Vertical"); Vector3 moveDir = new Vector3(horizontal, 0, vertical); transform.position += moveDir * speed * Time.deltaTime; }

单独看这段代码，逻辑没有错。但实际跑起来，角色每帧都被直接硬搬到一个新坐标上，完全没有任何过渡。玩家按下 A 键的瞬间，角色立刻以全速横移；松手瞬间，角色立刻归零。这会导致两个观感：第一，角色像悬空木偶，没有重量感；第二，如果同时按下斜向方向键，moveDir的模长会因为两个轴叠加变成约 1.414 倍，斜向跑会比直线跑快 41%，这就是"同样输入但速度不一致"的隐患。

真正的移动控制不该直接改position，而是应该管理一个"当前速度"，让这个速度每帧朝着"目标速度"逼近。Unity 里的CharacterController之所以推荐用Move，不是因为它是唯一方案，而是因为它顺带帮你处理了碰撞、坡度、台阶等问题，并且让你能以"速度向量"为中介来控制位移，而不是每帧硬修改坐标。

1.2 我先定一个协议：输入、请求速度、实际速度

我在项目里习惯把"移动"拆成三层，避免后面调的时候无从下手：

• 输入层：读取按键、手柄摇杆或触屏虚拟摇杆，输出一个Vector2，取值范围在 -1 到 1 之间；
• 请求层：把输入向量结合相机朝向，转换成世界空间里的"目标速度"Vector3，它表示角色此刻想以多快、往哪个方向跑；
• 实际速度层：让角色当前速度向目标速度逼近，逼近的快慢由加速度和减速度控制，最后把这个速度交给CharacterController.Move或Rigidbody。

这样拆分之后，"手感"就变成了几个非常具体的参数：加速度多大、减速度多大、转向速度多快、最大速度多少。调参的时候不再靠感觉瞎试，而是知道改的是哪一层。

这也是我建议新人在写移动前先做的事：不要一上来就写位移代码，先在纸上或者建模工具里确认清楚，你到底是想要即时的街机手感，还是偏重的写实手感。两种手感对参数的要求完全相反，后面所有代码都是围绕这个目标展开的。

2. 选型比写法更能决定上限：CharacterController 与 Rigidbody 的取舍

Unity 里做第三人称移动，最经典的选型分歧就是：用CharacterController还是用Rigidbody。很多教程会告诉你"CharacterController 适合动作游戏，Rigidbody 适合物理游戏"，但实际操作中远没有这么简单。

2.1 两套方案的实际表现差异

CharacterController本质上是一个可以移动的碰撞胶囊体，它的Move方法替你处理了碰撞检测，但它不是一个刚体，不会受到物理引擎的力、力矩、摩擦等影响。这意味着：

• 角色不会因为碰撞反弹，也几乎不受外部力的影响；
• 移动完全由你控制的velocity决定，非常适合精确控制角色；
• 但它没有惯性、摩擦，如果代码里不做平滑处理，就会出现"开灯即亮、关灯即灭"的生硬移动。

Rigidbody方案则是把角色当作真正的物理物体，配合capsule collider使用。优点是和场景里的物理交互更自然，比如被爆炸冲击、被移动平台带动；缺点是你要花很多精力去压制物理引擎的"自然行为"——比如角色站在斜坡上会滑动、被小障碍物卡住、摩擦力不好控制等。

我在实际项目里的经验是：如果你的目标是传统的动作冒险、第三人称射击、RPG，默认选择CharacterController会让你把精力集中在手感上，而不是和物理引擎搏斗。如果你的玩法本身以物理为核心，比如制作"传送门"式的解谜，或者需要很多物体推动、角色被击飞、角色站在浮板上，这时候Rigidbody会省掉大量外部交互的代码。

2.2 什么时候必须换用物理方案

有一种情况我建议果断换 Rigidbody：角色需要在移动平台之间跳来跳去，并且要求角色在平台移动时自然"粘"在平台上。CharacterController在这种情况下要写很多额外逻辑，判断脚下的地面是不是移动的，然后把移动平台的位移叠加给角色。Rigidbody 则天然会跟随彼此碰撞接触产生的约束。

另外，如果你在做一个多人在线游戏，同步移动状态时通常只同步"位置和朝向"而不是"速度"的话，CharacterController 和 Rigidbody 差异不大。如果非要同步速度做插值，Rigidbody 方案的速度值更符合物理直觉，预测插值更平滑。但这种情况比较进阶，刚起步的开发者不需要纠结。

我的建议是：不要因为喜欢某套方案就强行让玩法去适配它。先回答两个问题：角色是否需要频繁被外部物理力影响？你是否有精力处理摩擦和斜坡滑动的细节？一个"否"，选 CharacterController；两个都是"是"，选 Rigidbody。这个决策在写任何移动代码之前做，能帮你躲开后面一大半返工。

3. 输入处理与相机相对方向：解决"按W它往屏幕左边跑"

第三人称移动最容易让人困惑的地方之一，就是输入方向到底以什么为参考。如果你直接把摇杆的 X 轴对应transform.right，Y 轴对应transform.forward，然后让角色朝这两个方向移动，那么角色的朝向就直接决定移动方向。大多数情况下，这不符合第三人称的需求。

3.1 为什么不能直接用世界坐标的方向键

设想一个典型的第三人称视角：相机在角色身后上方，略微俯视前方。玩家按下"向前"键（即 W 或摇杆向上），他心里的预期是"角色朝屏幕上方移动"，也就是朝相机朝向在地面上的投影方向移动。但如果你把 W 映射成Vector3.forward（世界坐标的 Z 轴正方向），那么当相机旋转了 45 度时，角色按 W 会往地图的正北跑，而不是朝屏幕"向上"跑。玩家就会觉得方向完全不对。

更糟糕的是，如果相机本身是自由视野，玩家转动视角后，角色移动方向不会跟着调整，很快就会让玩家晕头转向。正确做法是：把输入向量从"屏幕坐标系"转换到"相机当前的朝向坐标系"。

3.2 把输入旋转到相机坐标系：公式与代码

实现上，先拿到相机的朝向和右向，将它们投影到地面上（消除俯仰角）并归一化，然后用这两个向量乘以输入值，合成移动方向：

Transform cameraTransform = Camera.main.transform; // 取相机正前方向在地面上的投影 Vector3 forward = cameraTransform.forward; forward.y = 0f; forward.Normalize(); // 取相机正右方向在地面上的投影 Vector3 right = cameraTransform.right; right.y = 0f; right.Normalize(); // moveInput 是读取到的摇杆/键盘输入，范围 [-1,1] Vector3 moveDir = right * moveInput.x + forward * moveInput.y; moveDir.Normalize(); // 防止斜向移动速度叠加过快

这个公式没什么高明之处，但它是所有第三人称移动的基石。这里有两个细节容易出问题：第一，相机正前方向量如果直接拿来用，会因为相机的俯仰角而产生 y 分量，导致角色朝下或朝上移动，所以必须把 y 清零再归一化；第二，moveDir.Normalize()必须在合成之后做，否则斜向移动速度会比直线移动快约 40%，这是很多"角色斜着跑特别快"问题的根源。

在 Unity 的旧版 Input Manager 里，Input.GetAxis("Horizontal")和Input.GetAxis("Vertical")已经是平滑的模拟值，直接用即可。如果用的是新版 Input System，则通常通过playerInput.actions["Move"].ReadValue<Vector2>()读取，需要注意它的默认更新模式是动态Dynamic Update，和旧版每帧同步更新的时机不同，可能会导致输入响应有轻微延迟，这在移动端的虚拟摇杆上要额外注意。

3.3 两种常见的相机参考模式

除了上述"相对于相机视方向"的模式外，还有两种模式需要区分：

• 固定相机参考：移动方向始终基于一个固定世界方向或固定相机方向。常见于世界地图的 45 度视角俯视角游戏。此时输入向量不需要跟相机实时绑定，直接用平面上的固定 forward/right 合成即可。
• 角色相对参考：移动方向始终以角色自身朝向为参考。常见于"坦克式操作"的设计，角色朝向移动方向，玩家需要转向时角色也旋转。这种模式下，位移方向等于角色 forward，输入只管前后左右旋转。

到底用哪种，取决于你的游戏设计。大部分第三人称动作游戏采用"相对相机"模式，因为玩家可以自由控制镜头视角，角色的移动方向自动跟随镜头，操作门槛最低。如果能配合"角色朝向转向移动方向"的处理，就能实现"移动跟手"的效果。

4. 相机跟随并不简单：平滑插值、碰撞避让与镜头抖动

第三人称移动的体验，有一半由相机决定。相机调好了，角色手感即使差一点也可以接受；相机调得烂，角色手感再好玩家也会骂。这一章节说说我在实际项目中踩过最多的坑。

4.1 不要让相机成为角色的子物体

很多新手会把相机直接拖到角色模型下，做成子物体，这样角色移动相机自然跟随。但这样做会立刻引发两个严重问题：角色旋转时相机跟着旋转，玩家视角会一起转，极易眩晕；而且角色在移动过程中如果有任何微小的朝向抖动，相机也会跟着抖，画面观感非常不稳定。

正确的做法是：相机完全独立于角色，通过代码在每帧LateUpdate之后更新位置，让相机始终看向角色身上的一个"注视点"，并在这个期望位置和当前相机位置之间做平滑插值。

public Transform target; // 角色的注视点，通常是头部或胸口 public Vector3 offset; // 相机相对注视点的偏移，比如 (0, 1.6f, -3.2f) public float smoothing = 8f; void LateUpdate() { // 期望位置是注视点中心加上偏移量 Vector3 desiredPosition = target.position + offset; // 使用基于指数衰减的平滑，避免帧率影响 float t = 1f - Mathf.Exp(-smoothing * Time.deltaTime); transform.position = Vector3.Lerp(transform.position, desiredPosition, t); // 始终看向注视点 transform.LookAt(target.position + Vector3.up * 0.2f); }

这里的核心细节是t = 1f - Mathf.Exp(-smoothing * deltaTime)。很多教程会直接写Vector3.Lerp(a, b, 0.1f)，这在 60 帧下看着还行，但到了 30 帧或者有掉帧时，插值系数跟着每帧时间变化，相机的平滑就会失真：快帧时追得紧，慢帧时拖得很远。用指数衰减公式后，插值系数和帧率无关，无论什么帧率，相机跟随时长都一致。

4.2 相机穿墙与避让：不要用 Linecast 解决所有问题

第三人称最糟糕的体验，莫过于墙挡住你之后镜头直接怼到角色脸上或者穿过墙面。一般做法是：从角色的注视点向相机期望位置打一条射线或者 SphereCast，如果中间有遮挡，就把相机位置拉回到碰撞点，然后再加一个很小的distanceFromWall偏移，比如 0.3 米。

推荐用SphereCast而不是单纯的Linecast。因为在墙角或者窄走廊里，球体检测的半径能模拟相机本身的体积，避免镜头贴着墙面还是穿进去半边的现象：

Vector3 lookAtPosition = target.position + Vector3.up * 0.2f; Vector3 desiredPosition = lookAtPosition + offset; if (Physics.SphereCast(lookAtPosition, 0.2f, desiredPosition - lookAtPosition, out RaycastHit hit, offset.magnitude, obstacleMask)) { // 在碰撞点基础上向相机方向偏移一段距离，凑近主角 desiredPosition = hit.point - (desiredPosition - lookAtPosition).normalized * 0.3f; }

这段逻辑建议放在 LateUpdate 里，配合前面的平滑插值一起用。注意一个问题：如果你给相机套了obstacleMask，一定要把角色身体自己所在的 Layer 排除掉，否则射线一打到自己就立刻把相机拉到脸上，镜头就抖得没法看了。这个问题我遇到过不止一次，调了半天才发现是射线把自己的碰撞体也算进去了。

4.3 镜头抖动：方向向量归一化的坑

另一个常见抖动来源是：相机期望位置计算中，如果LookAt的目标点或者角色朝向因为控制器判定二帧间产生了微小抖动，相机也会跟着一起抖动。特别是角色在奔跑后突然停住、速度向量归零的瞬间，如果角色的注视点绑定在角色头部骨骼上，骨骼动画的微小位移就会直接反映到镜头。

解决办法有两个：一是把注视点放在一个固定高度的Transform上，而不是直接绑定动态骨骼；二是在相机旋转之前，把Vector3方向归一化后再使用，避免乘以零向量导致LookRotation产生全零 Look 方向时 Unity 的自动修正行为造成滑丝。

我经常用下面的代码做一个"软注视"：

Vector3 lookPoint = target.position + Vector3.up * 1.2f; Quaternion desiredRot = Quaternion.LookRotation(lookPoint - transform.position); float rotT = 1f - Mathf.Exp(-cameraRotSpeed * Time.deltaTime); transform.rotation = Quaternion.Slerp(transform.rotation, desiredRot, rotT);

这样即使角色在细微晃动，镜头也不会突然被拽着走，旋转速度完全由参数控制，手感容易调很多。

5. 手感调优的关键参数与实测记录：把数值调到"感觉"

代码都跑通之后，真正的重头戏才开始：调手感。我在项目里通常会暴露四个参数，然后在 Play 模式里一边跑一边调，直到角色跑起来"不滑、不呆、不飘"。

5.1 加速度和减速度：解决"像滑冰"的核心

很多人做出来的角色"滑"，本质上是因为移动代码里只有"目标速度"而没有"速度变化过程"。角色每帧直接跳到目标速度，玩家按下方向键的瞬间角色就开始全速移动，松手瞬间速度归零。真实世界里的人和动物移动都有惯性，加速和减速需要时间。所以在代码里，我通常会维护一个currentVelocity，每帧向targetVelocity逼近：

public float maxSpeed = 6f; public float acceleration = 12f; public float deceleration = 24f; Vector3 currentVelocity; void Update() { Vector3 targetVelocity = moveDir * maxSpeed; // 根据是否有输入选择使用加速度还是减速度 float speedChange = moveDir.sqrMagnitude > 0.01f ? acceleration : deceleration; currentVelocity = Vector3.MoveTowards(currentVelocity, targetVelocity, speedChange * Time.deltaTime); characterController.SimpleMove(currentVelocity); }

Vector3.MoveTowards的好处是速度变化是线性的，不会因为帧率波动导致加速度忽大忽小，比Lerp更容易调试。在实际项目里，acceleration我一般取值 8 到 12，deceleration取值 20 到 30。加速度小于 6 时角色起手会感觉很"肉"，像脚底有黏胶；减速度小于 10 时松手后会滑出去一大截，就是大家熟悉的"冰面感"。

如果游戏需要更真实的惯性，比如模拟载具或者角色冲刺后的惯性漂移，可以把减速度调低到 5 到 8，并且把currentVelocity.Normalize改成保留一小部分速度余量，让角色自然减速到停。但这个设计对操作精度要求较高，用于竞速类游戏比较多。

5.2 转向速度：角色朝向和移动方向的一致性

第三人称里，角色肢体面向方向与移动方向的关系，直接影响玩家对角色的"跟手"判断。比如你按"向前"，角色应该跑步，如果角色头部和身体还面相屏幕中央，就会很违和。我们需要让人物模型平滑朝向移动方向。

常见做法是让模型自身朝向实时追向移动方向，但不要采用硬切。硬切会导致角色瞬间转头，动画还没跟上，视觉上像被扯了一下。我用的是：

if (moveDir.sqrMagnitude > 0.01f) { Quaternion targetRotation = Quaternion.LookRotation(moveDir, Vector3.up); modelTransform.rotation = Quaternion.Slerp( modelTransform.rotation, targetRotation, rotationSpeed * Time.deltaTime); }

注意旋转的是模型子物体（modelTransform），而不是控制器本身。这样可以保持CharacterController胶囊体的碰撞朝向不变，不受角色外观朝向影响。如果整个角色对象跟着旋转，那么相机的相对方向会因为角色的旋转而产生细微抖动，万一移动方向和相机 x 轴正好垂直，会产生自主振荡，表现就是"角色转圈"。

rotationSpeed取值上，动作游戏我习惯 12 到 18，写实类可以降到 6 到 8，让转身有迟钝感。如果你在做一个 3D 平台跳跃游戏，最好把转向速度调到 25 以上，保证跳跃方向精确可控。

5.3 教练视角：三组实测手感参数参考

下面这张表是我在测试第三人称演示项目时记录的实际参数，并非绝对标准，但可以作为起步参考：

我建议先按表格里的起始值跑通，然后只改其中一个参数，感受它对手感的影响，再做组合调整。一次改太多参数，你根本不知道是哪个参数导致手感变化。

6. 动画同步与根运动：让移动看起来像"走"而不是"滑行"

代码控制位移跑到 60 帧，动画却在模型上播放，如果两者脱节，玩家看到的就是角色在冰面上"滑行"。动画系统必须和移动状态对齐。

6.1 Blend Tree 与本地速度分解

第三人称移动动画一般用 Animator 的 Blend Tree，把移动动画（待机、走、跑、转向）按速度值混合。关键点在于，给 Blend Tree 的两个参数不是直接拿输入向量传进去，而是把角色的实际速度转换到角色本地坐标系下，再传给 Animator：

Vector3 localVelocity = transform.InverseTransformDirection(characterController.velocity); animator.SetFloat("ForwardSpeed", localVelocity.z); animator.SetFloat("LateralSpeed", localVelocity.x);

为什么要转换到本地坐标？因为 Blend Tree 里的x和z是相对模型朝向而言的。如果你的移动方向和模型朝向在某个瞬间不一致，这段差值会被修正，动画就能准确播放对应的转向和位移动作。如果你直接把世界方向的velocity塞给 Animator，角色往右横移时，Blend Tree 会认为此时应该播放"后退"动画，表现就会错乱。

另外需要注意characterController.velocity包含重力导致的 y 分量，如果直接用，ForwardSpeed会被往下偏移。在实际处理中，我会先把velocity.y清零再转换：

Vector3 planarVelocity = characterController.velocity; planarVelocity.y = 0f; Vector3 localPlanarVelocity = modelTransform.InverseTransformDirection(planarVelocity);

这样 Blend Tree 的"向前"参数只反映水平移动速度，重力对动画方向没有任何影响。

6.2 Root Motion 的取舍：动画驱动还是代码驱动

Unity 动画组件默认带Apply Root Motion勾选项。当动画片段里包含位移时，勾选后角色位置会被动画中的位移驱动。在第三人称移动中，我建议默认关闭Root Motion，改用代码驱动位移。原因很简单：玩家输入是即时的，代码驱动的响应速度远高于动画数据流的响应，动画里就算有一点位移，你把它当成辅助表现即可，不要让它参与主移动逻辑。

什么时候要开 Root Motion？当某个动画片段要求精确的演出位移时，比如翻滚、被击退、跳跃滞空中的身位变化、剧情动画中的角色走动。这些场景如果代码去模拟动画位移，很容易出现"动画手已经按地，角色却还在空中"的穿帮。我通常的做法是：普通移动代码驱动，特殊演出动画开启 Root Motion 并通过动画事件在特定帧播放，两者互不干扰。

还有一个常见问题：如果坚持使用 Root Motion，位移和代码速度会叠加，导致角色移动速度翻倍。如果确实要在某个动画里开启 Root Motion，记得在进入状态的那一刻把代码移动速度清零，或者用Animator.applyRootMotion = false在普通状态下强制关闭，等需要时再打开。

7. 高频问题排查：斜坡滑移、贴墙抖动与相机穿墙

即使原理都懂了，实操中仍会遇到一些不易排查的问题。我整理了下面几个项目里反复出现的情况，如果你遇到类似表现，可以顺着这个思路排查。

7.1 下坡飘离地面的具体处理

很多团队把重力计算放在Update里，每次只叠加很小一个量，结果就是角色走下坡时，重力还没来得及把它拉回地面，半秒内角色会处于悬浮状态。正确做法是把重力累加到velocity.y上，再在Move之前判断是否在地面上：

if (characterController.isGrounded) { velocity.y = -2f; // 保持与地面贴合，防止悬空 } else { velocity.y += Physics.gravity.y * Time.deltaTime; } characterController.Move(velocity * Time.deltaTime);

注意velocity应该是每秒的速度，而Move接收的是每帧位移，所以乘了deltaTime。这个-2f的小值是很多项目里会忽略但非常关键的细节，它确保角色站在任何轻微斜坡上时都能紧贴地面，而不是因为重力前一帧累积不足而被地面弹起。

7.2 CharacterController 的 slopeLimit 和台阶

CharacterController的slopeLimit默认是 45 度，超过该角度的坡面会被视为墙壁，角色无法登上。如果游戏里有较陡的坡道，你需要实测并调高这个值，或者用自定义的爬坡检测。stepOffset默认值只有 0.1 到 0.2 米，如果台阶高度略高于它，角色会被卡住。要处理台阶，可以把stepOffset调大到接近角色的膝盖高度，但注意它不能超过capsule collider高度的一半，否则角色会把门框、低矮障碍也跨过去，产生新的穿模问题。

7.3 输入延迟的排查：旧的 Input Manager 与新的 Input System

如果你使用新版 Input System 后感觉角色操控"肉"，检查一下 Player Settings 里的 Active Input Handling。如果旧项目从默认改为 Input System 后，仍然在 Update 里读取Input.GetAxis，会发现读取不到任何值，因为旧的输入 API 不再工作。新版 Input System 还支持在FixedUpdate和Update中对动态输入的读取行为不同，若项目里有FixedUpdate中的移动逻辑，输入会每隔固定物理帧读取一次，这会造成明显的操作延迟。解决方案是把输入读取放在Update中，而把位移计算放在FixedUpdate或者Update中保持一致。

最后再分享一个小技巧

独立调完第三人称移动之后，我发现最容易被忽视的是"真机测试"。反复在编辑器里调好的参数，拿到手机上可能完全不是一回事：一方面是屏幕刷新率差异，另一方面是触屏虚拟摇杆的响应和键盘完全不同。我现在的习惯是，每个项目在进入手感调优阶段之前，先做一个最简单的真机 Build，把摇杆和跟随相机的基本功能跑通一次，然后再开始调参。每次调完参数后不是只在编辑器里按几次方向键，而是实际跑上十来分钟，让手指和眼睛都适应一遍。只有在真实设备上跑过，你才会发现比如"松手后角色仍然往前走半步"这类问题，光是盯着编辑器里的帧数据是看不出来的。希望这篇随笔记能让你在第三人称移动这件事上少走几圈弯路。