很多刚接触 Unity 的人第一个想做的功能往往就是“让角色动起来”。而“动起来”这件事第一步不是写位移逻辑而是先搞清楚你按了键盘上的 W、A、S、D到底是怎么变成游戏里那个方块的位移的。这个中间环节就是输入系统。这篇文章我不打算讲那种“把代码全贴出来让你抄”的套路那对你的成长没什么帮助。我准备从输入方式的底层逻辑开始拆一直拆到完整可跑的移动脚本再聊聊我这些年在新旧两套输入系统之间切换时踩过的坑。看完你应该能理解为什么有人用Input.GetAxis有人用Input.GetKey还有人非要用新输入系统以及你自己该选哪条路。1. 输入方式选型先搞清楚你的项目到底适合哪一套1.1 旧版输入管理器Input Manager为什么还没被淘汰Unity 里最传统的输入方式是通过UnityEngine.Input这个类来读键盘、鼠标、手柄的输入。它背后对应的是 Edit - Project Settings - Input Manager 面板里那一长串 Axis轴配置。默认就给你配好了 Horizontal水平轴A/D 和左/右方向键、Vertical垂直轴W/S 和上/下方向键、Jump、Fire1、Fire2 等等。这套老系统最方便的一点就是“开箱即用”。你新建一个脚本写一行float h Input.GetAxis(Horizontal);就能读到键盘输入不需要任何额外的配置。而且GetAxis自带平滑过渡你按下一个键返回值不会瞬间从 0 跳到 1而是有一个加速度过程松开之后也有阻尼衰减。这个手感变化在角色移动里非常关键能让位移看起来不是“咔哒”一下硬切而是自然的加速减速。但它在实际项目里也有一些恶心的地方。第一Axis 的配置是全局的你想给某个特定 UI 界面单独禁用键盘输入得自己写逻辑控制。第二老输入系统处理多玩家分屏时特别费劲手柄和键盘的事件流是混在一起的你很难区分“1P 按了跳跃”还是“2P 按了跳跃”。第三它在 WebGL 平台和部分移动平台上有些兼容性差异尤其是焦点切换后输入丢失的问题排查起来很头疼。1.2 新输入系统Input System带来的变化和它的代价Unity 推新输入系统Input System Package已经很多年了它和老系统最大的区别是把“输入”这件事从“直接读数值”变成了“先绑定 Action再监听事件”。你的逻辑不再关心玩家按的是键盘的 A 还是手柄的方向键左你只需要定义一个名为“Move”的 Action方向值拿去用就行。用新系统你会频繁接触三个概念Actions Asset输入配置资产、Action Maps动作组、Bindings具体绑定比如“键盘的 W 键”。这样做的好处很明显跨平台输入统一了同一套代码在 PC、主机、移动端都能跑多玩家识别也容易每个玩家可以有自己的 InputDevice 和 ActionsUI 事件和游戏事件天然分离不需要你手动挡输入。代价就是学习曲线陡峭而且项目里多了一套需要维护的配置资产。比如你改了一个 Action 的名字生成代码也要跟着变团队协作时经常因为配置资产冲突吵起来。还有一点新输入系统的回调是事件驱动的你在Update()里直接写if (moveAction.IsPressed())这种主动查询方式当然可以但更常见的写法是订阅started、performed、canceled三个事件初学的人很容易绕晕。1.3 实际选型建议什么阶段选什么系统我个人给的建议其实不太“技术洁癖”完全看你的项目兜底和团队习惯做 3D 入门 Demo、Game Jam 小游戏、课程作业直接上老系统。别犹豫世界是残酷的但也是简单的。做 PC/移动端双平台发售的小型独立游戏也先考虑老系统。除非你对多手柄多玩家有硬需求。做主机的多人在线、本地多人、或者高性能竞技场景直接上新系统别用老系统硬扛。你迟早要迁移不如早点迁移。如果是新建项目Unity 2022 以上版本默认安装时都不再自动启用老系统而是问你要不要安装新系统包。你可以通过 Edit - Project Settings - Player - Active Input Handling 来切换选 Input Manager (Old)、Input System (New)、或 Both两者都启用。选 Both 最保险这样两套代码能并行调试但注意打包体积和性能会多一点开销。2. 键盘输入数值背后的秘密从物理按键到位移量2.1 GetAxis 和 GetKey 到底返回了什么很多新手会以为Input.GetKeyDown(KeyCode.W)和Input.GetAxis(Vertical)是等价的其实差别很大。Input.GetKey和Input.GetKeyDown是“布尔型”查询。GetKey表示“这帧按键一直处于按住状态”GetKeyDown表示“这一帧刚刚按下”。它们不关心键程、不关心力度、不关心手柄摇杆的角度只有 0 和 1 两种状态。所以直接用GetKey驱动移动脚本速度是死的没有任何平滑除非你在脚本里手动插值。Input.GetAxis返回的是“带量”的浮点数范围一般设定为 -1 到 1。键盘按下时它不会瞬间跳满而是按你在 InputManager 里设置的Sensitivity灵敏度和Gravity重力往目标值靠近。以默认的 Horizontal 轴为例按下 A 键后数值会从 0 平滑地降到 -1松开后又会回落到 0。这种设计本意是给手柄摇杆用的因为摇杆推到底是有中间物理过程的但键盘本身没有“推一半”的概念Unity 只是用一套公式模拟了这个过渡感。那这两个方式该怎么选做“像素级精确”的格斗游戏或者强调瞬间反应的平台跳跃我建议直接用GetKeyDown因为不需要过渡按下就是按下手感干脆利落。做普通的 3D 角色移动、俯视角 2D 移动GetAxis更合适它自带的缓动效果能减轻“机械感”让角色看起来更自然。如果你想让移动手感进一步可控甚至可以从GetAxisRaw没有平滑的 -1/0/1出发在代码里完全掌控加速度那样手感最统一但代码量也会多一些。2.2 Vector3 方向标准化为什么有人跑得比你快一倍老生常谈的问题你写移动逻辑时如果用Vector3 movement new Vector3(h, 0, v)直接拿去乘速度发现角色斜向移动时速度会变快。原因是水平方向 A/D 给一个 x 分量垂直方向 W/S 给一个 z 分量当两个轴同时输入时合成向量的模长不是 1而是 1.414也就是 √2。比如你只按 D向量是 (1,0,0)模长是 1但如果你按了 D 又按 W向量是 (1,0,1)模长就是 √2 ≈ 1.414。如果你的移动速度是设定好的speed 5那斜着跑时实际速度就是 5 × 1.414 ≈ 7.07。解决办法也很简单用.normalized把向量拉回 1 的模长Vector3 inputDir new Vector3(h, 0f, v).normalized; transform.position inputDir * speed * Time.deltaTime;这样斜向移动的速度就跟正向移动保持一致了。这个坑几乎每个做过 3D 移动的人都踩过我自己早期做的第一个第三人称 Demo 就是斜着跑飞快怎么调都调不好后来才发现问题不在速度数值而在向量方向没归一化。2.3 Time.deltaTime 到底为什么必须乘这一步是新手最容易忽略、却对移动精度影响最大的。Time.deltaTime实际上是“上一帧到这一帧实际消耗的时间秒”。Unity 的Update()不是按固定时间间隔执行的帧率不稳定时两帧之间的时间差会变化。如果你直接写transform.position direction * speed;在帧率 30FPS 和 60FPS 两种情况下角色每秒移动的距离完全不同。60FPS 时每帧移动量小但帧数多30FPS 时每帧移动量大但帧数少最终速度差异接近一倍。把位移量乘以Time.deltaTime等于把“每帧移动固定距离”转换成了“每秒移动固定距离”这个事情就变成了时间层面的匀速。无论帧率怎么波动角色一秒钟走过的距离基本恒定。这里我补一个小提醒如果你要和刚体Rigidbody配合用物理引擎移动角色尽量把对刚体的速度或力赋值写在FixedUpdate()里并且用Time.fixedDeltaTime。物理引擎的默认刷新频率是 0.02 秒如果你在Update()里给刚体加力会因为帧率和物理刷新频率不一致导致抖动尤其在联机同步时很明显。3. 写一套能直接跑的第三人称键盘移动脚本3.1 前置准备场景和角色配置我假设你已经有一个 Unity 项目随便新建一个场景加一个平面当地面创建一个胶囊体Capsule代表玩家角色。为了让移动看起来直观给胶囊体挂一个材质颜色比如亮蓝色方便看方向变化。然后给胶囊体添加CharacterController组件。这个组件是 Unity 官方提供的一个集成了碰撞检测、斜坡滑动、台阶自动跨越的“角色控制器”比你自己写Rigidbody再处理一堆碰撞细节要省事太多。注意CharacterController不会自动响应物理力它和刚体是两套体系你用transform.position移动它或者用它的Move()/SimpleMove()方法移动都行。如果你更想用Rigidbody做移动也是可以的。那个方案我更建议在物理需求强的项目里用比如角色会被击飞、会被爆炸波及。做传统“键盘控制走路”CharacterController是我的首选因为它的碰撞体形状是胶囊符合人形角色惯例而且自带的isGrounded判断做落地、跳跃检测很方便。3.2 老输入系统版完整脚本下面这个脚本我用老输入系统实现目标很简单WSAD 控制角色在平面上前后左右移动角色朝向跟随移动方向。using UnityEngine; public class PlayerMovement : MonoBehaviour { private CharacterController controller; [Header(移动参数)] public float moveSpeed 6f; public float rotateSpeed 720f; // 每秒旋转的角度 private void Awake() { controller GetComponentCharacterController(); } private void Update() { // 读取老输入系统的水平和垂直轴 float h Input.GetAxisRaw(Horizontal); float v Input.GetAxisRaw(Vertical); // 输入方向向量归一化防止斜向速度翻倍 Vector3 inputDir new Vector3(h, 0f, v).normalized; // 世界空间下的移动方向假设角色朝向就是正前方 Vector3 moveDir transform.TransformDirection(inputDir); // 通过 CharacterController 的 Move 方法移动 controller.Move(moveDir * moveSpeed * Time.deltaTime); // 如果玩家有输入让角色平滑转向输入方向 if (inputDir.sqrMagnitude 0.01f) { Quaternion targetRotation Quaternion.LookRotation(moveDir); transform.rotation Quaternion.RotateTowards( transform.rotation, targetRotation, rotateSpeed * Time.deltaTime ); } } }这里面有两个细节值得讲。第一我用了GetAxisRaw而不是GetAxis。原因是我希望输入净值干净然后自己在代码里控制旋转和移动的平滑度。如果用自带缓动的GetAxis会和“移动速度”叠加出一个不直观的手感调试时很难判断到底是哪个环节在拖沓。当然也有人就喜欢那种软绵绵的缓动手感那你可以换回GetAxis试试感受一下差别。第二transform.TransformDirection(inputDir)的作用是把“角色自身坐标系里的方向”转换成“世界坐标方向”。这句代码虽然是最传统的写法但隐含的前提是角色初始朝向蓝色箭头对着世界坐标的 Z 正方向摄像机不参与角色前方向计算。如果你的角色是第三人称跟随这个写法就不够用了因为角色移动方向应该跟随摄像机的朝向而不是角色自己的朝向。下面那段会聊。3.3 摄像机参与移动方向第三人称该有的移动逻辑第三人称游戏里玩家按下 W 的心理预期是“角色往屏幕里走”而不是“往世界坐标固定方向走”。如果摄像机转到角色侧面你再按 W角色不能傻乎乎地往世界坐标 Z 轴跑它得往摄像机镜头看的方向跑。核心思路是把摄像机的正前方向和正右方向拆出来作为移动的两个基准轴。private void Update() { float h Input.GetAxisRaw(Horizontal); float v Input.GetAxisRaw(Vertical); // 摄像机的正前方向忽略 y 轴影响 Vector3 camForward Camera.main.transform.forward; Vector3 camRight Camera.main.transform.right; camForward.y 0f; camRight.y 0f; camForward.Normalize(); camRight.Normalize(); // 移动方向 摄像机前方向 * 垂直输入 摄像机右方向 * 水平输入 Vector3 moveDir camForward * v camRight * h; if (moveDir.sqrMagnitude 0.01f) { moveDir.Normalize(); controller.Move(moveDir * moveSpeed * Time.deltaTime); Quaternion targetRotation Quaternion.LookRotation(moveDir); transform.rotation Quaternion.RotateTowards( transform.rotation, targetRotation, rotateSpeed * Time.deltaTime ); } }这里有个踩坑点如果摄像机朝下俯视Camera.main.transform.forward的 y 分量就不是 0直接用这个方向移动角色会往地下钻或者飘起来所以要把 y 分量清零再归一化。摄像机跟随的脚本我一般单独写不跟移动脚本混在一起。经典做法是写一个CameraFollow脚本用LateUpdate()让摄像机位置跟随目标角色并保持一个固定偏移。注意必须放在LateUpdate()里因为移动在Update()中执行LateUpdate()保证所有移动逻辑完成后摄像才去对准位置不然会出现轻微画面抖动。3.4 输入与跳跃和重力移动只是第一步只做水平移动有点单调下面我把跳跃和重力也补充进去。用CharacterController时重力并不像刚体那样自动施加你得自己模拟public float jumpHeight 1.5f; public float gravity -9.8f; private float verticalVelocity 0f; private void Update() { // 水平移动逻辑同上... // 垂直方向重力与跳跃 if (controller.isGrounded verticalVelocity 0f) { verticalVelocity -2f; // 让角色贴地而不是强制为0 } if (Input.GetKeyDown(KeyCode.Space)) { verticalVelocity Mathf.Sqrt(jumpHeight * -2f * gravity); } verticalVelocity gravity * Time.deltaTime; controller.Move(new Vector3(0f, verticalVelocity, 0f) * Time.deltaTime); }verticalVelocity的初值我习惯设成 -2 而不是 0这是从老项目里保留下来的小技巧。CharacterController.isGrounded判定有微小延时如果直接设成 0角色在斜坡或台阶边缘偶尔会出现微微浮空的感觉。给一个小的向下的负速度等于告诉控制器“你在往下贴”可以改善贴地稳定性。Mathf.Sqrt(jumpHeight * -2f * gravity)是物理公式v² 2gh的变形用来算出“要让角色跳起指定高度初速度要多大”。比如重力是 -9.8跳跃高度想达到 1.5 米代入后Mathf.Sqrt(1.5 * 2 * 9.8) ≈ 5.42也就是起跳瞬间垂直速度要 5.42m/s。这个公式我每次写跳跃都会用你不需要死记硬背理解原理下次也能推算出来。4. 我用新输入系统重写一遍Actions 配置和代码生成4.1 创建专门的输入控制资产如果你跟着上面的步骤做了一遍掌握了老系统的移动逻辑那迁移到新输入系统的过程其实很顺。新系统本质上只是把“读输入”的环节换成了“读 Action 的值/响应事件”移动计算逻辑并不变。先在 Window - Package Manager 里找到Input System包并安装。装完之后Unity 会推荐你重启编辑器并切换 Active Input Handling 到新系统。我建议在项目早期就定下来别用 Both因为两套系统同时启用会让 Input Manager 面板里的一些配置失效排查起来容易精神分裂。新建一个 Input Actions 资产的方法是在 Project 窗口右键 - Create - Input Actions命名比如PlayerControls。双击打开在 Actions 面板里添加一个 Move 的 Action类型选Value控制类型选Vector2。然后在右边 Bindings 区域点击加号添加两个绑定一个绑WASD 键盘的 2D 向量合成Unity 默认在 2D Vector 的 Composite 里绑定 W/S 和 A/D另一个绑左摇杆。如果你只要键盘不需要加摇杆绑定。设置完记得点右上角的 Save Asset然后关掉窗口。回到 Project 面板你会看到资产旁边多了一个同名的.cs文件这是 Unity 自动生成的 C# 代码里面定义了PlayerControls类。看这个文件能帮你理解新系统的事件结构。4.2 使用生成的 C# 类来驱动角色移动实例化自动生成的类在OnEnable里启用OnDisable里禁用。取值方式我推荐用ReadValueVector2()这是主动查询模式跟老系统的GetAxisRaw非常接近。using UnityEngine; public class PlayerInputSystem : MonoBehaviour { private PlayerControls controls; private CharacterController controller; public float moveSpeed 6f; private void Awake() { controller GetComponentCharacterController(); controls new PlayerControls(); } private void OnEnable() { controls.Enable(); } private void OnDisable() { controls.Disable(); } private void Update() { Vector2 input controls.Gameplay.Move.ReadValueVector2(); Vector3 moveDir new Vector3(input.x, 0f, input.y).normalized; controller.Move(transform.TransformDirection(moveDir) * moveSpeed * Time.deltaTime); } }这样看新系统的主动查询写法和老系统差距没有想象中那么大只是输入源从全局 Input 类变成了实例化的controls对象。但如果你需要事件驱动比如“按下跳跃”触发一次性的逻辑可以这样private void Awake() { controls new PlayerControls(); controls.Gameplay.Jump.performed OnJumpPerformed; } private void OnJumpPerformed(UnityEngine.InputSystem.InputAction.CallbackContext context) { // 这里不是 Update 每帧调用只在按键触发的瞬间调用 Debug.Log(Jump performed!); }事件驱动的好处是逻辑不会在每帧反复检查状态性能、代码可读性都更好。代价是你得把“调用关系”在脑子里理清楚谁订阅了谁、谁触发谁、什么时候解除订阅。初学时容易漏掉OnDisable解绑导致场景切换后脚本还残留在事件总线里静态引用无法释放。这里我补充一个实测经验新输入系统的事件回调是在固定帧的特定时机执行的如果你的游戏逻辑里需要“按下那一刻”的记录最好把时间戳也放在回调里取比如Time.time。不要在回调里直接调用Time.deltaTime相关的移动计算因为回调的触发频率和Update()的调用频率不完全一致很容易出现一次跳跃按下去触发两次位移叠加的怪情况。5. 输入相关的常见问题排查与避坑清单5.1 移动速度与预期不符这应该是踩坑频率第一的问题。首先是斜向速度翻倍我已经提到过用normalized解决。其次如果你是用了Rigidbody但忘了乘Time.deltaTime或者乘了两次速度也会不对。第三种情况是你把移动代码写在FixedUpdate()里但用的是Update()的帧间隔物理帧率和渲染帧率不一致速度就会时快时慢。这里我给一个自查顺序先确定移动逻辑在哪个生命周期里 - 检查所有moveSpeed乘的是不是对应的时间增量 - 检查方向向量有没有归一化 - 检查CharacterController有没有被其他脚本重复赋值位置。我见过很多人最后一步出问题两个脚本同时改同一个transform.position互相打架表现就是角色鬼畜抖动。5.2 按键无反应但编辑器不报错这种情况多半是在新输入系统资产里配置出了问题常见原因有三个没有在OnEnable启用controls只有Awake里实例化是没用的Action 不会自动激活。Input Actions 资产里绑定冲突比如同一个键既绑了 Move 又绑了 UI 的 Submit冲突时 Unity 默认保留后出现的一个但这在排查时很难一眼看出来。打包后在网页端或者移动端跑焦点不在游戏窗口上导致输入接收不到。老系统有Input.GetKey的重置行为新系统也有InputSystem.pollingFrequency和焦点模式的处理差异你需要在 OnApplicationFocus 里做处理或者检查项目的 Run In Background 设置。另外还有一种隐蔽情况场景里有两个对象都挂了同一个PlayerInputSystem脚本都实例化了PlayerControls两者互相订阅和取消订阅最后你发现响应声音正常但角色不动。这不是新手专属问题我组里一个同事调试了半天才发现场景里残留了一个不可见的老角色物体。5.3 跳跃触发了两次或三次这是在“本地多人 事件驱动”的设计下很容易翻车的问题。老系统里你写if (Input.GetKeyDown(KeyCode.Space))每帧只可能执行一次跳跃逻辑。新系统里如果你同时订阅了started和performed一个键按下去会触发两个时间段的事件如果你没区分跳跃逻辑就被调用两次。我的建议是一个输入动作的“开始、持续、结束”三个状态你只订阅你需要的那一个。比如跳跃订阅performed就够了不要同时订阅started。这个区别在动作类游戏里会直接影响手感、连击判定和状态机的推进。5.4 新旧系统同时启用的隐藏风险最后再强调一下Active Input Handling 选 Both 是“老项目迁移期”的临时方案不是长期配置。两套系统同时活跃帧率输入采样和性能消耗都会增加更重要的是行为差异可能造成逻辑覆盖。比如你写了一段老系统的移动逻辑写了一段新系统的移动逻辑两个都挂在同一个角色上它们各自读取键盘各算各的位移最后角色要么原地抽搐要么飞出去。这个排查难点在于两个脚本都会正常执行、都不报错表现又很像随机 bug很容易浪费时间。所以我的建议是新项目直接 New老项目明确排一个迁移计划不要在代码里同时保留两套输入路径超过一个迭代周期。6. 一点个人经验与手感调整心得移动这块做到“能跑”很容易但把键盘手感调出“舒服”的感觉才算是真正入了门。我调试手感时一般用一套固定的自查流程先检查输入是否干净有无抖动、误触再检查移动速度是否符合玩法预期然后检查旋转速度和转向是否有迟滞感最后跑一遍斜坡、台阶、墙角等碰撞密集区域看角色有没有卡顿或弹跳。有些地方我觉得值得你多花点时间琢磨第一moveSpeed的具体数值不是拍脑袋定的它得配合你的摄像机距离、场景尺度、角色体量一起看。比如一个 1.8 米高的胶囊体角色在 5x5 的测试房间里跑速度 6m/s 可能还行但如果你把场景放大到 50x50还觉得角色移动慢那其实不是速度问题是你场景设计比例不对。我早期做过一个开放场景 Demo把角色速度拉到 20m/s 才觉得“跑得起来”后来发现是场景里所有建筑都做大了三倍角色比例偏小根本不是速度的问题。第二旋转速度rotateSpeed也值得单独调。我常用 360 到 720 度每秒。如果你做的是 ARPG 或者有自动锁定目标的战斗旋转速度会直接影响打击感和指向容错调成一个固定值往往不够最好在角色移动状态和转向状态里用不同度数。第三CharacterController的参数里有个skinWidth默认是 0.08。它在角色靠墙时扮演“物理皮肤”的角色。值调大一些能减少角色陷墙的抖动但调太大又会让角色看起来飘在墙外一截。这个参数不是所有项目都需要动但如果遇到贴墙时相机穿模、角色模型抖动可以往这个方向查。最后说一个我常用的“慢热启动”技巧把移动速度做一点平滑滤波比如用Mathf.Lerp(moveSpeed, targetMoveSpeed, Time.deltaTime * 8f)。角色从静止到全速会有一小段加速过程停下来也同样有减速这种手感在“偏写实”的项目里很有效。反过来竞技性强的游戏比如平台跳跃、快节奏 Roguelike就不建议加这个按键瞬间就要给人完全可控的感觉任何迟滞都等于手感粘滞。做输入这套东西本质上是给“人的意图”翻译成“程序指令”再加一层“手感装修”。键盘按下那一刻系统怎么知道你想要多快转向、多快起步、越过怎样的物理阻挡全靠你在代码里一层一层设计出来。看再多的教程不如自己动手改几次参数跑进场景里感受一下。把每一个变量的效果都亲身体会过一遍下次不管换成手柄还是换成触屏虚拟摇杆你都能很快接住新方案的逻辑。希望你今天写完这个脚本之后多花一点时间改参数感受不同数值组合下角色“看起来像不像一个活人”。这比单纯把功能做出来有意思多了你会发现游戏手感这个东西跟写业务代码完全不是一回事。 
长河君 · 2026/10/17 12:39:13 · 阅读 1.2k Unity输入系统全解析：从键盘按键到角色移动的完整实践指南
很多刚接触 Unity 的人第一个想做的功能往往就是“让角色动起来”。而“动起来”这件事第一步不是写位移逻辑而是先搞清楚你按了键盘上的 W、A、S、D到底是怎么变成游戏里那个方块的位移的。这个中间环节就是输入系统。这篇文章我不打算讲那种“把代码全贴出来让你抄”的套路那对你的成长没什么帮助。我准备从输入方式的底层逻辑开始拆一直拆到完整可跑的移动脚本再聊聊我这些年在新旧两套输入系统之间切换时踩过的坑。看完你应该能理解为什么有人用Input.GetAxis有人用Input.GetKey还有人非要用新输入系统以及你自己该选哪条路。1. 输入方式选型先搞清楚你的项目到底适合哪一套1.1 旧版输入管理器Input Manager为什么还没被淘汰Unity 里最传统的输入方式是通过UnityEngine.Input这个类来读键盘、鼠标、手柄的输入。它背后对应的是 Edit - Project Settings - Input Manager 面板里那一长串 Axis轴配置。默认就给你配好了 Horizontal水平轴A/D 和左/右方向键、Vertical垂直轴W/S 和上/下方向键、Jump、Fire1、Fire2 等等。这套老系统最方便的一点就是“开箱即用”。你新建一个脚本写一行float h Input.GetAxis(Horizontal);就能读到键盘输入不需要任何额外的配置。而且GetAxis自带平滑过渡你按下一个键返回值不会瞬间从 0 跳到 1而是有一个加速度过程松开之后也有阻尼衰减。这个手感变化在角色移动里非常关键能让位移看起来不是“咔哒”一下硬切而是自然的加速减速。但它在实际项目里也有一些恶心的地方。第一Axis 的配置是全局的你想给某个特定 UI 界面单独禁用键盘输入得自己写逻辑控制。第二老输入系统处理多玩家分屏时特别费劲手柄和键盘的事件流是混在一起的你很难区分“1P 按了跳跃”还是“2P 按了跳跃”。第三它在 WebGL 平台和部分移动平台上有些兼容性差异尤其是焦点切换后输入丢失的问题排查起来很头疼。1.2 新输入系统Input System带来的变化和它的代价Unity 推新输入系统Input System Package已经很多年了它和老系统最大的区别是把“输入”这件事从“直接读数值”变成了“先绑定 Action再监听事件”。你的逻辑不再关心玩家按的是键盘的 A 还是手柄的方向键左你只需要定义一个名为“Move”的 Action方向值拿去用就行。用新系统你会频繁接触三个概念Actions Asset输入配置资产、Action Maps动作组、Bindings具体绑定比如“键盘的 W 键”。这样做的好处很明显跨平台输入统一了同一套代码在 PC、主机、移动端都能跑多玩家识别也容易每个玩家可以有自己的 InputDevice 和 ActionsUI 事件和游戏事件天然分离不需要你手动挡输入。代价就是学习曲线陡峭而且项目里多了一套需要维护的配置资产。比如你改了一个 Action 的名字生成代码也要跟着变团队协作时经常因为配置资产冲突吵起来。还有一点新输入系统的回调是事件驱动的你在Update()里直接写if (moveAction.IsPressed())这种主动查询方式当然可以但更常见的写法是订阅started、performed、canceled三个事件初学的人很容易绕晕。1.3 实际选型建议什么阶段选什么系统我个人给的建议其实不太“技术洁癖”完全看你的项目兜底和团队习惯做 3D 入门 Demo、Game Jam 小游戏、课程作业直接上老系统。别犹豫世界是残酷的但也是简单的。做 PC/移动端双平台发售的小型独立游戏也先考虑老系统。除非你对多手柄多玩家有硬需求。做主机的多人在线、本地多人、或者高性能竞技场景直接上新系统别用老系统硬扛。你迟早要迁移不如早点迁移。如果是新建项目Unity 2022 以上版本默认安装时都不再自动启用老系统而是问你要不要安装新系统包。你可以通过 Edit - Project Settings - Player - Active Input Handling 来切换选 Input Manager (Old)、Input System (New)、或 Both两者都启用。选 Both 最保险这样两套代码能并行调试但注意打包体积和性能会多一点开销。2. 键盘输入数值背后的秘密从物理按键到位移量2.1 GetAxis 和 GetKey 到底返回了什么很多新手会以为Input.GetKeyDown(KeyCode.W)和Input.GetAxis(Vertical)是等价的其实差别很大。Input.GetKey和Input.GetKeyDown是“布尔型”查询。GetKey表示“这帧按键一直处于按住状态”GetKeyDown表示“这一帧刚刚按下”。它们不关心键程、不关心力度、不关心手柄摇杆的角度只有 0 和 1 两种状态。所以直接用GetKey驱动移动脚本速度是死的没有任何平滑除非你在脚本里手动插值。Input.GetAxis返回的是“带量”的浮点数范围一般设定为 -1 到 1。键盘按下时它不会瞬间跳满而是按你在 InputManager 里设置的Sensitivity灵敏度和Gravity重力往目标值靠近。以默认的 Horizontal 轴为例按下 A 键后数值会从 0 平滑地降到 -1松开后又会回落到 0。这种设计本意是给手柄摇杆用的因为摇杆推到底是有中间物理过程的但键盘本身没有“推一半”的概念Unity 只是用一套公式模拟了这个过渡感。那这两个方式该怎么选做“像素级精确”的格斗游戏或者强调瞬间反应的平台跳跃我建议直接用GetKeyDown因为不需要过渡按下就是按下手感干脆利落。做普通的 3D 角色移动、俯视角 2D 移动GetAxis更合适它自带的缓动效果能减轻“机械感”让角色看起来更自然。如果你想让移动手感进一步可控甚至可以从GetAxisRaw没有平滑的 -1/0/1出发在代码里完全掌控加速度那样手感最统一但代码量也会多一些。2.2 Vector3 方向标准化为什么有人跑得比你快一倍老生常谈的问题你写移动逻辑时如果用Vector3 movement new Vector3(h, 0, v)直接拿去乘速度发现角色斜向移动时速度会变快。原因是水平方向 A/D 给一个 x 分量垂直方向 W/S 给一个 z 分量当两个轴同时输入时合成向量的模长不是 1而是 1.414也就是 √2。比如你只按 D向量是 (1,0,0)模长是 1但如果你按了 D 又按 W向量是 (1,0,1)模长就是 √2 ≈ 1.414。如果你的移动速度是设定好的speed 5那斜着跑时实际速度就是 5 × 1.414 ≈ 7.07。解决办法也很简单用.normalized把向量拉回 1 的模长Vector3 inputDir new Vector3(h, 0f, v).normalized; transform.position inputDir * speed * Time.deltaTime;这样斜向移动的速度就跟正向移动保持一致了。这个坑几乎每个做过 3D 移动的人都踩过我自己早期做的第一个第三人称 Demo 就是斜着跑飞快怎么调都调不好后来才发现问题不在速度数值而在向量方向没归一化。2.3 Time.deltaTime 到底为什么必须乘这一步是新手最容易忽略、却对移动精度影响最大的。Time.deltaTime实际上是“上一帧到这一帧实际消耗的时间秒”。Unity 的Update()不是按固定时间间隔执行的帧率不稳定时两帧之间的时间差会变化。如果你直接写transform.position direction * speed;在帧率 30FPS 和 60FPS 两种情况下角色每秒移动的距离完全不同。60FPS 时每帧移动量小但帧数多30FPS 时每帧移动量大但帧数少最终速度差异接近一倍。把位移量乘以Time.deltaTime等于把“每帧移动固定距离”转换成了“每秒移动固定距离”这个事情就变成了时间层面的匀速。无论帧率怎么波动角色一秒钟走过的距离基本恒定。这里我补一个小提醒如果你要和刚体Rigidbody配合用物理引擎移动角色尽量把对刚体的速度或力赋值写在FixedUpdate()里并且用Time.fixedDeltaTime。物理引擎的默认刷新频率是 0.02 秒如果你在Update()里给刚体加力会因为帧率和物理刷新频率不一致导致抖动尤其在联机同步时很明显。3. 写一套能直接跑的第三人称键盘移动脚本3.1 前置准备场景和角色配置我假设你已经有一个 Unity 项目随便新建一个场景加一个平面当地面创建一个胶囊体Capsule代表玩家角色。为了让移动看起来直观给胶囊体挂一个材质颜色比如亮蓝色方便看方向变化。然后给胶囊体添加CharacterController组件。这个组件是 Unity 官方提供的一个集成了碰撞检测、斜坡滑动、台阶自动跨越的“角色控制器”比你自己写Rigidbody再处理一堆碰撞细节要省事太多。注意CharacterController不会自动响应物理力它和刚体是两套体系你用transform.position移动它或者用它的Move()/SimpleMove()方法移动都行。如果你更想用Rigidbody做移动也是可以的。那个方案我更建议在物理需求强的项目里用比如角色会被击飞、会被爆炸波及。做传统“键盘控制走路”CharacterController是我的首选因为它的碰撞体形状是胶囊符合人形角色惯例而且自带的isGrounded判断做落地、跳跃检测很方便。3.2 老输入系统版完整脚本下面这个脚本我用老输入系统实现目标很简单WSAD 控制角色在平面上前后左右移动角色朝向跟随移动方向。using UnityEngine; public class PlayerMovement : MonoBehaviour { private CharacterController controller; [Header(移动参数)] public float moveSpeed 6f; public float rotateSpeed 720f; // 每秒旋转的角度 private void Awake() { controller GetComponentCharacterController(); } private void Update() { // 读取老输入系统的水平和垂直轴 float h Input.GetAxisRaw(Horizontal); float v Input.GetAxisRaw(Vertical); // 输入方向向量归一化防止斜向速度翻倍 Vector3 inputDir new Vector3(h, 0f, v).normalized; // 世界空间下的移动方向假设角色朝向就是正前方 Vector3 moveDir transform.TransformDirection(inputDir); // 通过 CharacterController 的 Move 方法移动 controller.Move(moveDir * moveSpeed * Time.deltaTime); // 如果玩家有输入让角色平滑转向输入方向 if (inputDir.sqrMagnitude 0.01f) { Quaternion targetRotation Quaternion.LookRotation(moveDir); transform.rotation Quaternion.RotateTowards( transform.rotation, targetRotation, rotateSpeed * Time.deltaTime ); } } }这里面有两个细节值得讲。第一我用了GetAxisRaw而不是GetAxis。原因是我希望输入净值干净然后自己在代码里控制旋转和移动的平滑度。如果用自带缓动的GetAxis会和“移动速度”叠加出一个不直观的手感调试时很难判断到底是哪个环节在拖沓。当然也有人就喜欢那种软绵绵的缓动手感那你可以换回GetAxis试试感受一下差别。第二transform.TransformDirection(inputDir)的作用是把“角色自身坐标系里的方向”转换成“世界坐标方向”。这句代码虽然是最传统的写法但隐含的前提是角色初始朝向蓝色箭头对着世界坐标的 Z 正方向摄像机不参与角色前方向计算。如果你的角色是第三人称跟随这个写法就不够用了因为角色移动方向应该跟随摄像机的朝向而不是角色自己的朝向。下面那段会聊。3.3 摄像机参与移动方向第三人称该有的移动逻辑第三人称游戏里玩家按下 W 的心理预期是“角色往屏幕里走”而不是“往世界坐标固定方向走”。如果摄像机转到角色侧面你再按 W角色不能傻乎乎地往世界坐标 Z 轴跑它得往摄像机镜头看的方向跑。核心思路是把摄像机的正前方向和正右方向拆出来作为移动的两个基准轴。private void Update() { float h Input.GetAxisRaw(Horizontal); float v Input.GetAxisRaw(Vertical); // 摄像机的正前方向忽略 y 轴影响 Vector3 camForward Camera.main.transform.forward; Vector3 camRight Camera.main.transform.right; camForward.y 0f; camRight.y 0f; camForward.Normalize(); camRight.Normalize(); // 移动方向 摄像机前方向 * 垂直输入 摄像机右方向 * 水平输入 Vector3 moveDir camForward * v camRight * h; if (moveDir.sqrMagnitude 0.01f) { moveDir.Normalize(); controller.Move(moveDir * moveSpeed * Time.deltaTime); Quaternion targetRotation Quaternion.LookRotation(moveDir); transform.rotation Quaternion.RotateTowards( transform.rotation, targetRotation, rotateSpeed * Time.deltaTime ); } }这里有个踩坑点如果摄像机朝下俯视Camera.main.transform.forward的 y 分量就不是 0直接用这个方向移动角色会往地下钻或者飘起来所以要把 y 分量清零再归一化。摄像机跟随的脚本我一般单独写不跟移动脚本混在一起。经典做法是写一个CameraFollow脚本用LateUpdate()让摄像机位置跟随目标角色并保持一个固定偏移。注意必须放在LateUpdate()里因为移动在Update()中执行LateUpdate()保证所有移动逻辑完成后摄像才去对准位置不然会出现轻微画面抖动。3.4 输入与跳跃和重力移动只是第一步只做水平移动有点单调下面我把跳跃和重力也补充进去。用CharacterController时重力并不像刚体那样自动施加你得自己模拟public float jumpHeight 1.5f; public float gravity -9.8f; private float verticalVelocity 0f; private void Update() { // 水平移动逻辑同上... // 垂直方向重力与跳跃 if (controller.isGrounded verticalVelocity 0f) { verticalVelocity -2f; // 让角色贴地而不是强制为0 } if (Input.GetKeyDown(KeyCode.Space)) { verticalVelocity Mathf.Sqrt(jumpHeight * -2f * gravity); } verticalVelocity gravity * Time.deltaTime; controller.Move(new Vector3(0f, verticalVelocity, 0f) * Time.deltaTime); }verticalVelocity的初值我习惯设成 -2 而不是 0这是从老项目里保留下来的小技巧。CharacterController.isGrounded判定有微小延时如果直接设成 0角色在斜坡或台阶边缘偶尔会出现微微浮空的感觉。给一个小的向下的负速度等于告诉控制器“你在往下贴”可以改善贴地稳定性。Mathf.Sqrt(jumpHeight * -2f * gravity)是物理公式v² 2gh的变形用来算出“要让角色跳起指定高度初速度要多大”。比如重力是 -9.8跳跃高度想达到 1.5 米代入后Mathf.Sqrt(1.5 * 2 * 9.8) ≈ 5.42也就是起跳瞬间垂直速度要 5.42m/s。这个公式我每次写跳跃都会用你不需要死记硬背理解原理下次也能推算出来。4. 我用新输入系统重写一遍Actions 配置和代码生成4.1 创建专门的输入控制资产如果你跟着上面的步骤做了一遍掌握了老系统的移动逻辑那迁移到新输入系统的过程其实很顺。新系统本质上只是把“读输入”的环节换成了“读 Action 的值/响应事件”移动计算逻辑并不变。先在 Window - Package Manager 里找到Input System包并安装。装完之后Unity 会推荐你重启编辑器并切换 Active Input Handling 到新系统。我建议在项目早期就定下来别用 Both因为两套系统同时启用会让 Input Manager 面板里的一些配置失效排查起来容易精神分裂。新建一个 Input Actions 资产的方法是在 Project 窗口右键 - Create - Input Actions命名比如PlayerControls。双击打开在 Actions 面板里添加一个 Move 的 Action类型选Value控制类型选Vector2。然后在右边 Bindings 区域点击加号添加两个绑定一个绑WASD 键盘的 2D 向量合成Unity 默认在 2D Vector 的 Composite 里绑定 W/S 和 A/D另一个绑左摇杆。如果你只要键盘不需要加摇杆绑定。设置完记得点右上角的 Save Asset然后关掉窗口。回到 Project 面板你会看到资产旁边多了一个同名的.cs文件这是 Unity 自动生成的 C# 代码里面定义了PlayerControls类。看这个文件能帮你理解新系统的事件结构。4.2 使用生成的 C# 类来驱动角色移动实例化自动生成的类在OnEnable里启用OnDisable里禁用。取值方式我推荐用ReadValueVector2()这是主动查询模式跟老系统的GetAxisRaw非常接近。using UnityEngine; public class PlayerInputSystem : MonoBehaviour { private PlayerControls controls; private CharacterController controller; public float moveSpeed 6f; private void Awake() { controller GetComponentCharacterController(); controls new PlayerControls(); } private void OnEnable() { controls.Enable(); } private void OnDisable() { controls.Disable(); } private void Update() { Vector2 input controls.Gameplay.Move.ReadValueVector2(); Vector3 moveDir new Vector3(input.x, 0f, input.y).normalized; controller.Move(transform.TransformDirection(moveDir) * moveSpeed * Time.deltaTime); } }这样看新系统的主动查询写法和老系统差距没有想象中那么大只是输入源从全局 Input 类变成了实例化的controls对象。但如果你需要事件驱动比如“按下跳跃”触发一次性的逻辑可以这样private void Awake() { controls new PlayerControls(); controls.Gameplay.Jump.performed OnJumpPerformed; } private void OnJumpPerformed(UnityEngine.InputSystem.InputAction.CallbackContext context) { // 这里不是 Update 每帧调用只在按键触发的瞬间调用 Debug.Log(Jump performed!); }事件驱动的好处是逻辑不会在每帧反复检查状态性能、代码可读性都更好。代价是你得把“调用关系”在脑子里理清楚谁订阅了谁、谁触发谁、什么时候解除订阅。初学时容易漏掉OnDisable解绑导致场景切换后脚本还残留在事件总线里静态引用无法释放。这里我补充一个实测经验新输入系统的事件回调是在固定帧的特定时机执行的如果你的游戏逻辑里需要“按下那一刻”的记录最好把时间戳也放在回调里取比如Time.time。不要在回调里直接调用Time.deltaTime相关的移动计算因为回调的触发频率和Update()的调用频率不完全一致很容易出现一次跳跃按下去触发两次位移叠加的怪情况。5. 输入相关的常见问题排查与避坑清单5.1 移动速度与预期不符这应该是踩坑频率第一的问题。首先是斜向速度翻倍我已经提到过用normalized解决。其次如果你是用了Rigidbody但忘了乘Time.deltaTime或者乘了两次速度也会不对。第三种情况是你把移动代码写在FixedUpdate()里但用的是Update()的帧间隔物理帧率和渲染帧率不一致速度就会时快时慢。这里我给一个自查顺序先确定移动逻辑在哪个生命周期里 - 检查所有moveSpeed乘的是不是对应的时间增量 - 检查方向向量有没有归一化 - 检查CharacterController有没有被其他脚本重复赋值位置。我见过很多人最后一步出问题两个脚本同时改同一个transform.position互相打架表现就是角色鬼畜抖动。5.2 按键无反应但编辑器不报错这种情况多半是在新输入系统资产里配置出了问题常见原因有三个没有在OnEnable启用controls只有Awake里实例化是没用的Action 不会自动激活。Input Actions 资产里绑定冲突比如同一个键既绑了 Move 又绑了 UI 的 Submit冲突时 Unity 默认保留后出现的一个但这在排查时很难一眼看出来。打包后在网页端或者移动端跑焦点不在游戏窗口上导致输入接收不到。老系统有Input.GetKey的重置行为新系统也有InputSystem.pollingFrequency和焦点模式的处理差异你需要在 OnApplicationFocus 里做处理或者检查项目的 Run In Background 设置。另外还有一种隐蔽情况场景里有两个对象都挂了同一个PlayerInputSystem脚本都实例化了PlayerControls两者互相订阅和取消订阅最后你发现响应声音正常但角色不动。这不是新手专属问题我组里一个同事调试了半天才发现场景里残留了一个不可见的老角色物体。5.3 跳跃触发了两次或三次这是在“本地多人 事件驱动”的设计下很容易翻车的问题。老系统里你写if (Input.GetKeyDown(KeyCode.Space))每帧只可能执行一次跳跃逻辑。新系统里如果你同时订阅了started和performed一个键按下去会触发两个时间段的事件如果你没区分跳跃逻辑就被调用两次。我的建议是一个输入动作的“开始、持续、结束”三个状态你只订阅你需要的那一个。比如跳跃订阅performed就够了不要同时订阅started。这个区别在动作类游戏里会直接影响手感、连击判定和状态机的推进。5.4 新旧系统同时启用的隐藏风险最后再强调一下Active Input Handling 选 Both 是“老项目迁移期”的临时方案不是长期配置。两套系统同时活跃帧率输入采样和性能消耗都会增加更重要的是行为差异可能造成逻辑覆盖。比如你写了一段老系统的移动逻辑写了一段新系统的移动逻辑两个都挂在同一个角色上它们各自读取键盘各算各的位移最后角色要么原地抽搐要么飞出去。这个排查难点在于两个脚本都会正常执行、都不报错表现又很像随机 bug很容易浪费时间。所以我的建议是新项目直接 New老项目明确排一个迁移计划不要在代码里同时保留两套输入路径超过一个迭代周期。6. 一点个人经验与手感调整心得移动这块做到“能跑”很容易但把键盘手感调出“舒服”的感觉才算是真正入了门。我调试手感时一般用一套固定的自查流程先检查输入是否干净有无抖动、误触再检查移动速度是否符合玩法预期然后检查旋转速度和转向是否有迟滞感最后跑一遍斜坡、台阶、墙角等碰撞密集区域看角色有没有卡顿或弹跳。有些地方我觉得值得你多花点时间琢磨第一moveSpeed的具体数值不是拍脑袋定的它得配合你的摄像机距离、场景尺度、角色体量一起看。比如一个 1.8 米高的胶囊体角色在 5x5 的测试房间里跑速度 6m/s 可能还行但如果你把场景放大到 50x50还觉得角色移动慢那其实不是速度问题是你场景设计比例不对。我早期做过一个开放场景 Demo把角色速度拉到 20m/s 才觉得“跑得起来”后来发现是场景里所有建筑都做大了三倍角色比例偏小根本不是速度的问题。第二旋转速度rotateSpeed也值得单独调。我常用 360 到 720 度每秒。如果你做的是 ARPG 或者有自动锁定目标的战斗旋转速度会直接影响打击感和指向容错调成一个固定值往往不够最好在角色移动状态和转向状态里用不同度数。第三CharacterController的参数里有个skinWidth默认是 0.08。它在角色靠墙时扮演“物理皮肤”的角色。值调大一些能减少角色陷墙的抖动但调太大又会让角色看起来飘在墙外一截。这个参数不是所有项目都需要动但如果遇到贴墙时相机穿模、角色模型抖动可以往这个方向查。最后说一个我常用的“慢热启动”技巧把移动速度做一点平滑滤波比如用Mathf.Lerp(moveSpeed, targetMoveSpeed, Time.deltaTime * 8f)。角色从静止到全速会有一小段加速过程停下来也同样有减速这种手感在“偏写实”的项目里很有效。反过来竞技性强的游戏比如平台跳跃、快节奏 Roguelike就不建议加这个按键瞬间就要给人完全可控的感觉任何迟滞都等于手感粘滞。做输入这套东西本质上是给“人的意图”翻译成“程序指令”再加一层“手感装修”。键盘按下那一刻系统怎么知道你想要多快转向、多快起步、越过怎样的物理阻挡全靠你在代码里一层一层设计出来。看再多的教程不如自己动手改几次参数跑进场景里感受一下。把每一个变量的效果都亲身体会过一遍下次不管换成手柄还是换成触屏虚拟摇杆你都能很快接住新方案的逻辑。希望你今天写完这个脚本之后多花一点时间改参数感受不同数值组合下角色“看起来像不像一个活人”。这比单纯把功能做出来有意思多了你会发现游戏手感这个东西跟写业务代码完全不是一回事。