很多刚接触 Unity 的朋友第一个想做的功能就是“让角色动起来”。而“键盘控制人物移动”这个需求看似简单其实背后牵扯到输入系统、坐标空间、帧率与时间、物理碰撞、视角适配等一系列问题。尤其是“输入方式代码的编写”这一步如果一开始就偷懒后面做联机、做移动端适配、做自定义按键时会踩到不少坑。这篇文章我就从输入代码本身出发把 Unity 键盘控制人物移动的完整思路、几种主流写法、背后的原理以及我实际项目中踩过的问题一次聊透。适合刚学 Unity 的初学者也适合想回头把基础打扎实的开发者。这篇不会只给你一段能跑的代码就完事我会把“为什么这么写”也拆开讲清楚。因为输入获取这件事本质上是“玩家的操作意图”如何转成“角色在场景里的行为”这一步做得好不好直接决定手感。而手感恰恰是最难教、也最值钱的东西。1. 输入获取的基础逻辑代码里到底在“读”什么1.1 Unity 输入系统的层级结构Unity 的输入系统分两层底层是玩家按下的物理按键键盘、鼠标、手柄上层是 Unity 封装好的输入接口。我们在代码里做的事情本质上就是“轮询”——每一帧问一次 Unity玩家有没有按某个键按到哪个方向了传统输入系统里最常用的是Input类。这一类下面有几个经典方法Input.GetKey、Input.GetKeyDown、Input.GetAxis、Input.GetAxisRaw。初学阶段很多人会混用但这几个方法背后的行为差异非常大。GetKey只要键被按住每帧都返回 true。GetKeyDown只有在按下那一帧返回 true适合做跳跃这种“按一次触发一次”的操作。GetAxis返回一个平滑变化的浮点数从 0 渐变到 1 或 -1松手后也会渐变回 0。GetAxisRaw返回不经过平滑处理的 -1、0 或 1响应更直接。换句话说GetAxis适合需要细腻控制的场景比如手柄摇杆键盘这种数字按键用GetAxisRaw手感往往更干脆。默认的Horizontal和Vertical轴在旧版输入管理器里已经映射好了键盘的 A/D 和 W/S方向键也可以我们直接读就行。这里要注意一个很多教程不会提的细节Input.GetAxis返回的是“轴的值”不是“键的状态”。如果项目里用户在 Input Manager 里把轴的 Sensitivity 调高了你读到的值会变化。所以如果代码逻辑依赖“值为 1 时才移动”平滑轴可能导致角色在松开按键后还会滑行一小段。你可以在项目设置里控制这些参数也可以干脆用GetAxisRaw绕开。1.2 键盘输入的“死区”和响应习惯键盘和手柄不同它是数字输入digital input也就是按下/松开两个状态。但在实际游戏里我们希望角色移动是模拟量analog也就是有速度变化的。所以输入代码要干的第二件事就是把“数字按键”翻译成“模拟移动向量”。这就是为什么大多数移动代码都长这样float horizontal Input.GetAxisRaw(Horizontal); float vertical Input.GetAxisRaw(Vertical); Vector3 direction new Vector3(horizontal, 0f, vertical).normalized;.normalized这一步很多人会漏。它的作用是当 W 和 D 同时按下时向量是 (1, 0, 1)长度是 1.414如果不归一化斜向移动速度会比正向快 41%。这对“手感”来说是致命的。而键盘输入的“响应习惯”本质上就是希望“按下去就动、松开就停、斜向不加速”。理解了这一点你就明白为什么几乎所有移动代码都要先读输入、再归一化、最后乘以速度。2. 核心移动代码编写五种主流方式与选型逻辑2.1 最基础的 Transform 位移写法先给出最直观的版本这也是初学者最常写的using UnityEngine; public class PlayerMove : MonoBehaviour { public float moveSpeed 5f; void Update() { float h Input.GetAxisRaw(Horizontal); float v Input.GetAxisRaw(Vertical); Vector3 move new Vector3(h, 0f, v).normalized; transform.position move * moveSpeed * Time.deltaTime; } }这段代码能跑而且逻辑清晰。Time.deltaTime是必须加的因为Update每帧调用帧率不同会导致移动速度不同。加上它之后角色移动速度就变成了“每秒 5 米”的绝对速度而不是“每帧 5 米”的帧率相关速度。但这里有三个问题直接改transform.position不会触发物理碰撞。如果场景里有墙壁角色会直接穿过去。这个移动是“世界坐标方向”的角色面朝哪、镜头朝哪都不影响 W 键永远是“世界 Z 轴正方向”。角色本身没有旋转模型不会朝移动方向转向看起来像“漂移”。第一点决定了这个写法只能用于原型验证或非物理类游戏比如纯俯视角解谜、UI 演示。第二、第三点会在后文讲到。2.2 使用 CharacterController 的角色移动如果你做的是第三人称或第一人称 RPG、动作游戏更合理的方案是CharacterController。它自带胶囊碰撞体能处理墙壁阻挡、地面坡度、台阶跨越不需要你自己写碰撞响应逻辑。它也是旧版 Unity 官方示例里最常用的移动方案。using UnityEngine; [RequireComponent(typeof(CharacterController))] public class PlayerMoveCC : MonoBehaviour { public float moveSpeed 6f; private CharacterController controller; void Awake() { controller GetComponentCharacterController(); } void Update() { float h Input.GetAxisRaw(Horizontal); float v Input.GetAxisRaw(Vertical); Vector3 move new Vector3(h, 0f, v).normalized; controller.Move(move * moveSpeed * Time.deltaTime); } }CharacterController.Move和直接改transform.position最大的区别是它会做碰撞检测。遇到墙壁会停下下坡时会沿坡度滑行并且它支持isGrounded检测方便后续做跳跃和重力。注意我特意把moveSpeed设成 6而不是 5。这不是拍脑袋常见的第三人称角色步速大约在 5.5~7 m/s 之间太小像散步太大会飘。这个数值你完全可以按自己的项目调但知道“正常范围”能帮你快速定位是不是参数问题。2.3 基于 Rigidbody 的物理移动如果你的角色需要被力推动、被爆炸弹飞、或者要和大量物理对象交互那你就该用Rigidbody。但这里有一个很关键的原则不要直接修改Rigidbody的position或velocity来移动角色除非你真的知道自己在做什么。正确的做法是通过Rigidbody.MovePosition或者施加力。using UnityEngine; [RequireComponent(typeof(Rigidbody))] public class PlayerMoveRB : MonoBehaviour { public float moveSpeed 5f; private Rigidbody rb; void Awake() { rb GetComponentRigidbody(); } void FixedUpdate() { float h Input.GetAxisRaw(Horizontal); float v Input.GetAxisRaw(Vertical); Vector3 move new Vector3(h, 0f, v).normalized; rb.MovePosition(rb.position move * moveSpeed * Time.fixedDeltaTime); } }注意这里是FixedUpdate而不是Update。因为物理运算是在固定时间步长里进行的Rigidbody.MovePosition如果放在Update里位置更新会和物理步长不一致可能出现穿墙或抖动。Time.fixedDeltaTime配合FixedUpdate才能真正做到“物理帧率下的匀速移动”。为什么很多人说“Rigidbody 的移动比较难调”因为它受到物理材质、摩擦、阻力、碰撞材质等影响参数稍微不合适角色要么推不动要么刹不住车。所以我的建议是能用 CharacterController 的场景就不要用 Rigidbody除非你确实需要力相关的复杂交互。2.4 带角色转向的移动移动不只是位置变化还涉及朝向。常见做法是让角色的前方向 移动方向。最简单的写法是transform.rotation Quaternion.LookRotation(moveDirection)。Vector3 move new Vector3(h, 0f, v).normalized; if (move.magnitude 0.01f) { Quaternion targetRotation Quaternion.LookRotation(move); transform.rotation Quaternion.Slerp(transform.rotation, targetRotation, Time.deltaTime * 10f); }Quaternion.Slerp的作用是让转向变得平滑而不是瞬间跳变。Time.deltaTime * 10f中的 10 是转向速度调大一点会更有“转身干脆”的感觉调小则更柔和。这里需要加move.magnitude 0.01f的判断防止角色在静止时一直试图转到默认方向。转向与移动是两套逻辑但在代码里必须写在同一段流程中顺序是读输入 — 算方向 — 转向 — 移动。如果先移动再转向角色会出现“先走两步再转过来”的滞后感。2.5 相对于相机视角的移动很多教程做到上一步就停了但实际项目里玩家希望按 W 是“朝镜头看的方向前进”而不是“朝世界坐标的固定方向前进”。这就涉及相机变换的应用。Vector3 direction transform.forward * v transform.right * h; direction direction.normalized;这段代码用的是角色自己坐标系里的 forward 和 right效果是不管角色面向哪里W 都是朝它当前面朝的方向走。但问题是角色并不会主动朝镜头方向转。如果你希望移动方向跟随相机就需要先获取相机的前向方向再把输入投影到相机平面上。Transform cam Camera.main.transform; Vector3 forward cam.forward; forward.y 0f; forward.Normalize(); Vector3 right cam.right; right.y 0f; right.Normalize(); Vector3 moveDirection forward * v right * h;这个操作的原理是相机的 forward 不一定是水平的俯视角看地面时forward 是斜向下的所以要先去掉 y 分量再归一化否则角色移动会比预期慢。等你做完这一步角色的移动方向就和镜头完全挂钩了这也是主流第三人称游戏的标准手感基础。3. 输入代码里的关键细节坐标系、补帧与状态机3.1 世界坐标、本地坐标与屏幕坐标移动代码写多了你会发现坐标系是个绕不开的坎。直接改transform.position是世界坐标transform.Translate(move * speed * Time.deltaTime, Space.Self)是本地坐标而屏幕坐标在 UI 和移动端用到。三者怎么选简单原则是世界坐标角色移动方向不受自身旋转影响适合俯视角策略游戏。本地坐标角色的移动方向跟随自身旋转适合第三人称动作游戏。屏幕坐标用在摇杆、点击移动、UI 拖拽这些场景里。输入代码本身不关心坐标系但“把输入向量塞进哪个坐标系”决定移动行为。我见过一个常见 Bug角色明明按 W结果朝镜头右前方移动排查半天发现是摄像机旋转影响到了输入向量的计算。这个问题的本质就是把“本地输入意图”直接当成了“世界空间运动方向”。3.2 Time.deltaTime 与 Time.fixedDeltaTime 的区别这是一道经典面试题但在实际项目里很多人只是“加了个 deltaTime”却不理解为什么。简单说Time.deltaTime是“上一帧到这一帧的时间差”单位秒。它随帧率变化而变化用在 Update 里。Time.fixedDeltaTime是“物理步长”默认 0.02 秒即 50Hz。它不随帧率变化用在 FixedUpdate 里。如果你用 Rigidbody 移动却把速度乘在deltaTime上物理系统会收到的位置更新频率不稳定角色可能出现“一卡一卡”的感觉。如果你用 CharacterController 在 Update 里移动就必须用deltaTime因为它不是物理驱动组件它只是“带碰撞的 Transform 移动”。一个容易忽略的点CharacterController.Move内部其实也在做物理检测但它是基于非物理步长模拟的。所以在低帧率设备上CharacterController的移动会出现隧道效应快速移动穿过薄墙解决办法是帧率保持稳定或把移动拆分成多次小步长。这对移动端优化尤其重要。3.3 状态机思维输入只是条件不是行为本身写输入代码最忌讳的是把“按键状态”直接等同于“角色行为”。举个典型例子if (Input.GetKeyDown(KeyCode.Space)) { animator.Play(Jump); }这段代码按一下空格就播放一次跳跃动画听起来没问题。但如果角色在走路、跑步、倒退时都按了空格动画就会强制切到跳跃没有任何过渡。真正的手感来自“状态机管理”当前角色处于什么状态这个状态允许哪些输入输入到达后如何切换状态不是每个人都要在一开始就引入动画状态机但你至少应该在移动代码里预留一个判断条件比如if (canMove !isDead !isStunned) { Move(); }这个canMove会在你后续做受击硬直、对话暂停、UI 打开时派上大用场。很多新手因为一开始没写这个开关后期要把逻辑插回所有移动代码非常痛苦。所以输入代码的编写不只是“读一眼按键”它要为后续状态扩展留好门。4. 实操过程从零搭建一个键盘移动 Demo4.1 场景搭建与组件配置先说我的搭建习惯。创建一个 3D 场景地面用一个 Plane 放大到 10 倍给角色模型。如果你没有模型直接用自带 Capsule 也可以但记得加一个 Camera 并让它在角色后方俯视。角色对象挂CharacterController组件。在 Inspector 里你能看到它的属性比如Radius胶囊半径、Height高度、Center胶囊中心点。默认值通常是 0.5 半径、2 高度。但当角色手里拿着武器或需要蹲伏时这些参数需要动态调整。摄像机我建议用Cinemachine的 Free Look 相机因为这个组件自带跟随和视角旋转适合观察移动效果。如果你不想引入新包也可以用Camera.main.transform.SetParent(player.transform)直接让相机跟随但视角不会自动平滑。4.2 脚本编写的完整流程我建议把脚本拆成两个文件而不是把所有逻辑塞进一个 MonoBehaviourPlayerInput.cs负责轮询 Input把移动向量计算出来。PlayerMotor.cs负责接收移动向量并把它应用到 CharacterController 上。这样拆的好处是后续如果改成移动端虚拟摇杆你只需要换掉 PlayerInput 的实现PlayerMotor 完全不用动。我们来写一个最小可用的版本。// PlayerInput.cs using UnityEngine; public class PlayerInput : MonoBehaviour { public Vector3 MoveDirection { get; private set; } void Update() { float h Input.GetAxisRaw(Horizontal); float v Input.GetAxisRaw(Vertical); Vector3 input new Vector3(h, 0f, v).normalized; Transform cam Camera.main ? Camera.main.transform : transform; Vector3 forward cam.forward; forward.y 0f; forward.Normalize(); Vector3 right cam.right; right.y 0f; right.Normalize(); MoveDirection forward * v right * h; if (MoveDirection.magnitude 1f) MoveDirection.Normalize(); } }// PlayerMotor.cs using UnityEngine; [RequireComponent(typeof(CharacterController))] public class PlayerMotor : MonoBehaviour { public float moveSpeed 6f; public float rotationSpeed 10f; private CharacterController controller; private PlayerInput playerInput; private Vector3 velocity; void Awake() { controller GetComponentCharacterController(); playerInput GetComponentPlayerInput(); } void Update() { Vector3 move playerInput.MoveDirection; if (move.magnitude 0.01f) { controller.Move(move * moveSpeed * Time.deltaTime); Quaternion targetRotation Quaternion.LookRotation(move); transform.rotation Quaternion.Slerp(transform.rotation, targetRotation, Time.deltaTime * rotationSpeed); } else { // 不受外力时衰减水平速度便于以后接真实物理 velocity Vector3.zero; } } }这段代码里PlayerInput负责“读输入算方向”PlayerMotor负责“应用移动转向”。后续你要加跳跃、重力、跑步加速直接在 PlayerMotor 里扩充就行不用再翻输入那段代码。4.3 速度参数的调节技巧moveSpeed不是一个拍脑袋的常量。我的经验是先设一个基准速度比如 6 m/s。在场景里放两个相距 10 米的空物体实际走一遍看时间是否符合预期。10 米如果走了 2 秒速率就是 5 m/s。这个测试方法虽然朴素但特别有效。因为 3D 场景里的“视觉速度”和数值不一定匹配场景规模、相机距离都会影响你对速度的感知。如果你觉得移动特别慢先不要急着加数值先看看是不是相机离角色太远了。还有一个细节rotationSpeed在 10 左右时角色转向比较自然低于 5 会像在打太极。但如果你做的是“瞄准射击”类游戏转向应该更快甚至可以瞬间转向因为慢转向会让玩家在紧急情况下感觉角色“不听话”。5. 常见问题与排查技巧实录5.1 角色移动方向与按键方向不一致这是最常遇到的问题。原因主要有两种相机的 forward 和 right 没有去掉 y 分量导致移动向量包含上下方向。角色的模型网格本身没有对准 Unity 的正方向。排查方法在场景里旋转角色到 Rotation (0, 0, 0)看看模型的脸是不是朝向 Z 轴正方向。如果不是说明模型本身偏了。这时不要在代码里额外转 90 度最好是修改模型或加一个子节点把模型包在子节点里修正方向。代码里做旋转补偿是很坑的事后面做动画、做瞄准、做坐标抓取都会受影响。5.2 角色抖动或穿模如果你用的是Rigidbody移动在Update里调用rb.MovePosition就会抖动。解决办法是挪到FixedUpdate。如果你用的是CharacterController但角色身上同时又挂了一个Rigidbody很多新手会顺手挂上去也会出现奇怪的抖动因为两个系统都在改同一位置。穿模问题通常是移动速度过快、帧率过低、碰撞体太薄。CharacterController默认的检测步长是skinWidth默认 0.08如果你把角色速度调太高一帧里移动的位移超过了墙体厚度就会直接穿过。解决思路不是把skinWidth调到最小而是在移动前用Physics.SphereCast预检测一下前方是否有阻挡有阻挡就只移动剩余距离。5.3 斜向移动速度明显变快或变慢这个问题前面提过根源是向量未归一化。但还有一种情况你已经用了.normalized但斜向速度仍然感觉不对。此时检查你的输入向量里是不是混入了其他来源比如 Lerp 平滑过的摇杆值。float currentH Mathf.Lerp(Input.GetAxisRaw(Horizontal), targetH, Time.deltaTime * 10f);如果你对GetAxisRaw的 -1 和 1 做 Lerp得到的可能是一个 0.7 左右的浮点数。这个浮点数本身没问题但当你把它和另一个轴组合并归一化时可能会出现“数值永远到不了 1”或者“松手后还带一点残留速度”的情况。键盘输入本来就不需要平滑直接用GetAxisRaw就好了。5.4 快速按下和松开按键时角色“卡住”有读者遇到过快速点按 W 再松开角色会在原地卡一帧。原因是Input.GetAxisRaw在按键切换的瞬间可能返回 0然后立刻回到 -1 或 1。如果你在代码里写了“数值接近 0 时让速度归零”的逻辑就可能在一两帧里把速度清零导致角色短暂停滞。解决办法是给“速度归零”加一个缓冲判断比如if (Mathf.Approximately(move.magnitude, 0f))或者直接让角色在 Input 返回 0 时不做任何处理保留上一帧速度等外力来自然衰减。这个手感问题在帧率高的设备上不明显但在 30 帧的设备上会被放大。5.5 快速排查清单速查现象可能原因优先排查位置方向不对相机 forward 未去除 y 分量模型朝向不正PlayerInput / 模型子节点抖动Update 中使用 MovePosition多组件同时移动PlayerMotor / FixedUpdate穿墙速度过快、碰撞体过薄CharacterController 参数 / 移动步长斜向加速向量未归一化移动向量计算处原地漂移旋转未处理动画与移动冲突旋转逻辑 / Animator按键没反应Input Manager 的轴未配置输入系统冲突Project Settings / 包状态5.6 一个我在实际项目中踩过的大坑我曾经做过一个俯视角联机 Demo移动用的CharacterController主控角色一切正常但网络同步过来的其他角色全部在“抖”。一开始以为是网络插值问题折腾了三天最后发现是本地角色的CharacterController.Move在Update里跑而远端角色我图省事直接用了transform.position的差值同步导致帧率不一致时出现双写和回弹。这个问题给我留下的教训非常深刻所有移动行为无论本地还是远端都必须走同一套运动逻辑入口。后来我习惯把“移动”本身抽象成一个Move(Vector3 direction, float speed)方法本地和远端都调用这个方法只不过传入的方向来源不同。这个抽象让后面加网络同步、加 bot AI、加脚本事件移动都变得极其轻松。6. 从键盘到新输入系统为移动端和扩展做准备6.1 旧版输入系统的限制Unity 的老的Input类虽然写起来方便但它有几个硬伤不支持按键重绑定、不支持游戏手柄热插拔的高效处理、多个输入来源混用时不好区分。而且它在移动端上虚拟摇杆没法直接用Input.GetAxis驱动需要自己做 UITouch 的映射。新输入系统Input System Package可以解决这些问题。它把输入抽象成 Actions支持按键重映射、游戏手柄震动反馈、多个设备的输入优先级管理。虽然写起来略繁琐但一旦项目需求复杂起来这套系统几乎是必需品。// 新输入系统示例伪代码 using UnityEngine.InputSystem; public class PlayerInputNew : MonoBehaviour { public Vector2 moveInput; public void OnMove(InputValue value) { moveInput value.GetVector2(); } }新输入系统的核心是事件驱动而不是逐帧轮询。好处是你不需要在 Update 里去GetAxis输入值会主动回调给你。这样 CPU 开销更小逻辑也更清晰。缺点是需要理解InputActionAsset的配置流程初学者可能需要额外花一点时间。6.2 何时应该升级到新输入系统我的建议如果是长期项目、跨平台项目、或者你要接手柄一开始就上 Input System。如果你只是学基础、做练习或者项目只跑 PC 键盘旧的Input类完全够用。不要为了“新”而“新”输入系统的切换成本不只是代码还有所有按键的重新配置、动画参数绑定的调整、以及你团队里其他成员的学习成本。另一个务实的建议如果你决定用新输入系统务必关闭 Player Settings 里的旧输入系统支持或至少设为兼容模式。否则可能出现Input.GetKey报错、或两个系统抢输入源的问题。这个坑我也踩过项目跑着跑着突然按键失灵排查半天发现是 Player Settings 的 Active Input Handling 改成了 Both导致同一份代码被调用了两次。6.3 键盘控制的扩展方向跑步/蹲伏/瞄准移动输入写好后扩展方向非常多。最简单的扩展是“按住左 Shift 跑步”代码只要加一个速度切换float currentSpeed Input.GetKey(KeyCode.LeftShift) ? runSpeed : walkSpeed;“蹲伏”则更复杂一点因为你要改CharacterController的height和center而不是只改速度。蹲下时胶囊体的中心要下移否则视觉上看起来会陷进地面或穿出天花板。这个操作一定要用协程或者 Lerp 平滑过渡瞬间改高度会出现“抖动”和“卡头顶”的问题。“瞄准”则需要把角色移动速度降下来同时让角色朝向彻底交给镜头。这个时候移动代码里的转向逻辑和瞄准逻辑会产生冲突通常的解法是加一个isAiming布尔值瞄准时禁用移动方向转向角色朝向完全由镜头旋转驱动。这些扩展看似是操作逻辑但其实都发生在输入代码和移动代码的接口边界上。如果你一开始就把 PlayerInput读什么和 PlayerMotor怎么动拆开这些扩展都只是在已有接口上加一个数据字段的事完全不会把原有代码改得面目全非。我现在的习惯是每写一个移动脚本都会问自己一句话如果明天要加一个“按住右键瞄准、移动速度减半、角色朝向锁定镜头”的功能这个脚本需要改动多少行如果超过三行说明输入和移动的耦合还不够低。很多项目后面会越来越难改不是因为需求复杂而是早期把输入、移动、动画、视角全堆在一个脚本里改一个功能就像在拆一座叠叠乐。键盘控制人物移动从表面看只是一段读按键、改位置的代码但我做了几个项目回来再看发现它其实是整个角色控制系统的骨架。骨架歪了后面长出来的肌肉、神经、皮肤全都得跟着歪。这篇把输入获取、移动实现、坐标系、补帧、碰撞方式、以及新旧输入系统都过了一遍希望能让你的第一版移动代码就是一套能陪你走完整个项目的代码。