简介一份面向Unity初学者与游戏开发者的实操资料系统讲解如何利用WASD键和鼠标输入控制物体移动与视角旋转。资源为单份PDF文档压缩包约46KB内容紧凑、便于查阅。文档从场景搭建说起指导在场景中建立Capsule、将主摄像机挂为子物体并挂载C#脚本脚本覆盖W/A/S/D前后左右移动、空格键上升、F键下降以及鼠标左键拖拽旋转视角等完整逻辑同时附移动系数与旋转系数的调参说明方便直接复用或二次开发。文中还分析了该操作方式的优缺点及第一人称射击、第三人称射击、模拟游戏和虚拟现实等典型应用场景可帮助读者判断适用条件。已有10928人学习过该资源适合正在学习Unity基础操作、希望快速掌握典型移动控制方案的开发者参考。1. 你为什么按了 W物体却不动移动这件事比想象中更讲究在 Unity 里实现“键盘 WASD 控制物体移动”听起来是引擎最基础的操作但我在帮别人排查项目时发现同一个移动脚本有人用了三年都没出问题有人一放到高帧率显示器上就穿墙、抖动、斜着飞。原因在于移动不是一句transform.position ...就结束的事——它背后牵扯到输入源选型、物理组件取舍、帧率补偿、坐标系换算四层问题。这篇笔记不打算给你一份只会在原地打转的 Demo而是把从“按下按键”到“物体真正动起来”这条链路上的所有关键决策讲清楚再给出可以直接抄进项目的最小代码和参数。无论你是刚接触 Unity 的新手还是从其他引擎转过来的熟手照着这篇动手能少走很多弯路。2. 动手前先选型Transform、刚体还是角色控制器2.1 三类移动方案的适用边界与取舍Unity 里让物体动起来有三条常见路径直接改Transform、操作Rigidbody、使用CharacterController。不是每个场景都能随便选我见过一个新手项目用Transform直改去推一堵墙结果物体直接嵌进墙里物理引擎完全没反应。选型要先想清楚你的物体是“角色”还是“物件”。Transform直改是最直接也最容易出问题的方案。它适合背景装饰、UI 元素、非物理的机关物体。优点是代码简单、不依赖物理系统缺点是碰撞检测变成“事后补偿”物体高速移动时可能直接穿透碰撞体。CharacterController是 Unity 为“人形角色”设计的专用组件自带胶囊体碰撞能处理斜坡、台阶、碰撞滑动但不会响应物理力——你用不了AddForce它也不会被子弹打飞。Rigidbody则适合任何需要真实物理反馈的物体被撞击会弹开、有惯性、受重力影响、能和场景里的其他刚体交互。方案碰撞响应受力反馈适合场景性能开销Transform 直改穿透风险高无装饰物、UI、机关最低CharacterController自带胶囊碰撞无角色、NPC、玩家低Rigidbody完整物理引擎完整道具、载具、物理谜题高我的建议是按“物体是否需要被物理世界推着走”来一刀切需要就上Rigidbody不需要就用CharacterController只有纯视觉物体才用Transform直改。这个判断在项目初期花五分钟定下来能省掉后面无数次重写移动逻辑的血泪经验。2.2 Unity 输入源怎么选GetAxis 还是 GetKey输入侧同样有两条路线传统 Input Manager 的Input.GetAxis(Horizontal)以及逐帧监听Input.GetKey(KeyCode.W)。这里有个容易被低估的坑GetAxis默认带平滑滤波——你按下 W 后返回值不是瞬间变成 1而是从 0 渐变到 1 再渐变回 0。用GetAxis做出来的移动手感会自带“阻尼感”很接近主机游戏的摇杆操作。但它不适合需要精确响应的场合比如帧数敏感的跳跃缓冲、连招判定。我在做移动方案时习惯用Input.GetAxisRaw替代GetAxis。区别在名字里Raw 版本不做平滑滤波按下就是 1、松开就是 0没有中间态。这样方向判断是干净的后面想加手感就在Vector3.Lerp或Mathf.SmoothDamp上做文章而不是跟输入源的隐式平滑打架。如果需要同时支持键盘和手柄GetAxisRaw一样能读到摇杆值只是摇杆推一半时返回值是 0.5。按键映射用 Unity 默认的 “Horizontal” 和 “Vertical” 轴即可它们在 Project Settings 里已经绑定了 WASD 和方向键。不要手写GetKey去判断四个按键再拼装方向那是把引擎已经做好的事重做一遍。除非你要区分“只有 A 按下”和“AD 同按”否则默认轴足够。2.3 Update 还是 FixedUpdate时间基准决定帧率稳定性移动代码放哪个生命周期回调里直接决定你帧率高时会不会“飘”。Update的调用频率跟帧率走——帧率高时每秒调用次数多帧率低时调用次数少。如果直接在Update里写transform.position direction * speed那么同一个速度值在 144Hz 显示器上会跑得比 60Hz 快 2.4 倍。必须乘Time.deltaTime才能把“每帧的位移量”换算成“每秒的位移量”。Rigidbody的物理模拟默认按固定时间步长运行通常在 0.02 秒一次即每秒 50 次所以刚体移动代码放FixedUpdate更匹配物理步进。但注意Input.GetAxisRaw在FixedUpdate里读可能会漏掉快速按键——因为输入状态在每帧刷新一次而物理步进和帧率不一定是整倍数关系。所以我在项目里采用一个折中在Update里读取输入并存储到变量在FixedUpdate里消费这个变量去驱动刚体。这个“读输入、驱动物理分家”的习惯能避免大量时序类玄学 bug。3. 用 WASD 跑通最小移动代码、参数与装配步骤3.1 挂上脚本就能动的 Transform 直改方案先给一个完全最小化的可运行代码。新建一个空物体挂上这个脚本运行后按 WASD 就能看到物体会动。我在脚本注释里标了每个关键参数的作用方便你按自己的手感调整。using UnityEngine; public class BasicMovement : MonoBehaviour { // 移动速度单位米/秒 public float moveSpeed 5f; void Update() { // GetAxisRaw 返回 -1、0、1不含平滑滤波 float horizontal Input.GetAxisRaw(Horizontal); float vertical Input.GetAxisRaw(Vertical); // 把输入组合成三维方向向量normalized 保证斜向移动不超速 Vector3 inputDir new Vector3(horizontal, 0f, vertical).normalized; // 每帧位移 方向 * 速度 * 帧间隔时间 transform.position inputDir * moveSpeed * Time.deltaTime; } }这里最值得关注的是normalized。如果输入是 (1, 0, 1)不归一化时向量长度为 √2 ≈ 1.414物体斜着走的实际速度会比直线快 41%。新手经常在这个地方翻车表现为“直线走没感觉斜着走就飘”。归一化后向量长度恒为 1方向上的速度始终等于moveSpeed。Time.deltaTime的作用是让速度摆脱帧率影响。假设moveSpeed 560 帧时deltaTime约 0.0167 秒每帧位移约 0.083 米144 帧时约 0.0069 秒每帧位移约 0.035 米。两者一秒内的总位移都约等于 5 米这样不同配置的设备上运动速度才能一致。如果不乘144Hz 显示器上的物体会比 60Hz 快一倍还多这就是“同一段代码在不同电脑上跑出不同速度”的根源也是很多人以为是玄学实则是算术的地方。3.2 速度和方向的默认参数说明moveSpeed的取值不该拍脑袋它跟场景尺度强相关。假如你的场景里轨道宽度是 4 米角色 1 秒能横穿轨道的速度大概在 4 米/秒也就是把moveSpeed设为 4 到 6 比较合理。如果场景是室内走廊1.5 到 3 米/秒更真实如果做的是俯视角沙盒地图10 米/秒才感觉“走得不累”。一个可复现的验证方法是从场景起点按住 W 走 3 秒看物体移动的距离是否符合视觉预期。走太慢了调大数值走太快了调小别光看不动的数值。在Transform直改方案里方向向量只取了 X 和 Z 轴Y 轴恒为 0意味着物体不会上下浮动。如果挂这个脚本的物体原本有重力相关的逻辑比如自定义下坠代码这里的 Y 0 会在每一帧把竖直方向的速度清零表现出来就是物体“死在空中”。所以这个最小方案只适用于不参与物理的物体或者你主动把重力的处理留到别的方案里。3.3 换用新输入系统时 GetAxis 失效怎么处理如果你用的是 Unity 2022 之后的版本新建项目时可能默认启用新的 Input System 包。这种情况下Input.GetAxisRaw会在运行时直接抛异常或者在控制台打出InvalidOperationException: You are trying to read Input using the UnityEngine.Input class, but you have switched active Input handling to Input System package。很多人在这一步就以为是代码写错了折腾半天才发现是项目设置的问题。最快的切换路径是打开Edit Project Settings Player Active Input Handling把Input Manager改成Both。这样旧代码能继续用新系统也能跑。但“Both”模式有一点让人头疼它会同时编译两套输入底层在某些移动平台上有额外的包体开销和启动耗时。如果想彻底迁移到新系统写法是给脚本挂上一个PlayerInput组件或者在Awake里手动绑定单个 Actionusing UnityEngine; using UnityEngine.InputSystem; public class NewInputSystemMovement : MonoBehaviour { public float moveSpeed 5f; private Vector2 moveInput; private void OnEnable() { // 在 InputSystem 的默认 map 里找名为 Move 的 action var moveAction InputSystem.actions.FindAction(Move); moveAction.Enable(); moveAction.performed OnMove; moveAction.canceled OnMove; } private void OnMove(InputAction.CallbackContext context) { moveInput context.ReadValueVector2(); } private void OnDisable() { var moveAction InputSystem.actions.FindAction(Move); moveAction.performed - OnMove; moveAction.canceled - OnMove; } void Update() { // 新系统的输入是二维向量x横轴y纵轴 Vector3 dir new Vector3(moveInput.x, 0f, moveInput.y).normalized; transform.position dir * moveSpeed * Time.deltaTime; } }注意InputSystem.actions.FindAction(Move)依赖项目里存在一个全局可访问的 Input Action Map并且里面定义了名为 “Move” 的 Action。新建的 Input System 项目默认带的DefaultInputActions里输入动作叫 “Move”所以这段代码在默认项目里可以直接跑如果你的项目里没有这个 Action 资产会抛InvalidOperationException那就需要先创建。本质上新系统这套流程比旧的轴映射更规范但前期配置成本摆在那儿项目时间紧就先用Both模式过渡后续再迁移不迟。4. 让移动跟上物理刚体与角色控制器的进阶实现4.1 刚体移动为什么放在 FixedUpdate当物体需要“被推着走”或者“撞到东西要停”不能再用Transform直接改位置了。Transform.position相当于瞬移——这一帧你把它挪到碰撞体内部物理引擎要等到下一次碰撞检测才会发现问题于是高速行走时经常出现“卡进墙里然后被弹出来”的劣质手感。正确做法是把移动交给刚体的速度或力让物理引擎在自己固定步长里处理碰撞响应。using UnityEngine; public class RigidbodyMovement : MonoBehaviour { public float moveSpeed 5f; private Rigidbody rb; private Vector3 inputDir; void Awake() { rb GetComponentRigidbody(); // 限制刚体旋转防止轻微碰撞导致角色翻倒 rb.constraints RigidbodyConstraints.FreezeRotation; } void Update() { float horizontal Input.GetAxisRaw(Horizontal); float vertical Input.GetAxisRaw(Vertical); inputDir new Vector3(horizontal, 0f, vertical).normalized; } void FixedUpdate() { // 直接覆盖水平速度保留 y 轴速度让重力生效 Vector3 velocity new Vector3(inputDir.x * moveSpeed, rb.velocity.y, inputDir.z * moveSpeed); rb.velocity velocity; } }这段代码的关键是Update只存输入FixedUpdate才改刚体速度。原因前面说过FixedUpdate的调用频率与帧率无关而Rigidbody的内部模拟步长是固定的 0.02 秒。你如果在Update里改刚体速度实际上是在两次物理步进之间插入了额外的速度变化物理引擎无法正确补偿整体运动会出现微小的抖动。另外一个容易忽略的是FreezeRotation约束。Rigidbody默认对旋转没有任何限制物体撞到任何一个小的碰撞体都会产生转动力矩轻则晃动重则翻滚。对于人形角色、货运箱子这类需要“站稳”的物体冻结旋转是常态。反过来如果是球、轮胎、被撞飞的道具就不应该冻结旋转——物理趣味全在翻滚上。关于速度赋值的参数moveSpeed在这里同样是米/秒但注意直接赋值rb.velocity是“绝对速度控制”角色能瞬间达到最大速度手感偏“硬”。如果需要惯性感改用rb.AddForce或rb.velocity Vector3.Lerp(rb.velocity, targetVelocity, 0.1f)这种阻尼趋近的写法。Lerp的第三个参数是每次物理步进的趋近比例0.1 表示每步接近目标速度的 10%步长 0.02 秒时约 0.2 秒达到 87% 的最大速度这个手感很多动作游戏都在用。4.2 斜向移动归一化与相机空间方向上一节代码里已经写了normalized这里要单独展开它在物理方案里做得还不够的情况。如果场景是俯视角摄像机从正上方往下看用世界坐标轴做方向向量没问题。一旦摄像机是斜 45 度俯视或者越肩视角按 W 想让角色“朝屏幕里走”而不是“朝世界坐标的 Z 轴走”就需要把输入方向换算到相机空间。Vector3 GetCameraRelativeDirection(float horizontal, float vertical) { // 取相机 forward去掉 y 轴贡献保证角色不会朝天上/地下走 Vector3 forward Camera.main.transform.forward; forward.y 0f; forward.Normalize(); // 相机的 right 已经垂直于 forward无需额外处理 Vector3 right Camera.main.transform.right; // 组合方向前方向 * 垂直输入 右方向 * 水平输入 Vector3 moveDir forward * vertical right * horizontal; if (moveDir.sqrMagnitude 1f) { moveDir.Normalize(); } return moveDir; }这里必须把Camera.main.transform.forward投影到 XZ 平面再归一化否则俯视角度越大角色斜上走的倾向越明显。Camera.main在场景里没有标签为 “MainCamera” 的摄像机时会返回 null容易在运行时爆空引用建议在Awake里缓存引用而不是每次移动都查一次。相机这个方向跟后面的“摄像机跟随”话题直接相关——如果你用的是最简单的“把摄像机放在角色后面”的做法角色转弯后摄像机不转那按 W 的方向永远对不上。常见做法是在角色移动时把角色的 forward 也转向输入方向摄像机再去平滑跟随角色的位置和朝向或者反过来让摄像机保持固定朝向移动方向始终跟相机走比如俯视角塔防。这个取舍没有对错但决定你的输入代码是“角色朝向驱动”还是“相机方向驱动”别混用。4.3 CharacterController 方案的参数与手感调优CharacterController是另一个高性能选择适合做第三/第一人称角色。它自带胶囊碰撞体能走斜坡、自动处理碰撞滑动同时又不像Rigidbody那样会被场景里的力随意推动。下面是带重力处理的完整示例using UnityEngine; public class CharacterControllerMovement : MonoBehaviour { public float moveSpeed 6f; public float gravity -9.81f; public float jumpSpeed 0f; // 想做跳跃再改 private CharacterController controller; private Vector3 velocity; void Awake() { controller GetComponentCharacterController(); } void Update() { float horizontal Input.GetAxisRaw(Horizontal); float vertical Input.GetAxisRaw(Vertical); // 用角色自身的前方和右方来组合方向按角色的朝向移动 Vector3 move transform.right * horizontal transform.forward * vertical; move move.normalized * moveSpeed; // 简单重力落地时重置向下速度防止数值越积越大 if (controller.isGrounded velocity.y 0) { velocity.y -2f; } velocity.y gravity * Time.deltaTime; // Move 把所有位移打包给 CharacterController 处理碰撞 controller.Move((move new Vector3(0f, velocity.y, 0f)) * Time.deltaTime); } }CharacterController.Move会自己处理碰撞和滑动但有个细节经常让人发懵transform.right和transform.forward取决于角色的朝向。如果你的角色没有转向逻辑按 W 会朝世界前方走按 A 会朝世界左右走——这没问题但如果角色旋转了 90 度按 W 会朝世界 X 轴走感觉方向“乱了”。所以在挂CharacterController的项目里一般会让角色朝向跟随镜头的左右旋转再移动就自然匹配视觉方向了。CharacterController的参数里最影响手感的是Height、Radius、Step Offset和Slope Limit。Step Offset表示角色能无碰撞跨上的台阶高度默认 0.1 到 0.3 米太小的话走小台阶会被卡住太大的话会直接穿过不该过的台阶。Slope Limit默认 45 度超过这个角度的斜坡会被当成墙挡住。调这组参数的标准是“在目标场景里走一遍所有地形路径哪卡调哪”不建议凭感觉一次性拉满。5. 移动开发的常见坑与排查清单5.1 物体穿透碰撞体还抖动Transform 直改遇到物理碰撞现象用Transform.position ...移动一个挂有BoxCollider的方块快速推向一面墙时方块直接穿进墙体或在墙边剧烈抖动十次里有八次穿透。原因Transform直改位置是瞬移每一步都等于把物体强行移动到新坐标。物理引擎只在固定步长做一次碰撞查询物体速度过快时会跳过碰撞检测的“扫掠”过程导致在两次检测之间直接越过墙体。解决把移动逻辑迁移到Rigidbody用rb.velocity或者rb.MovePosition驱动让物理引擎在整个运动路径上持续检测碰撞。如果项目结构上不能换刚体就把单帧位移量限制在碰撞体厚度之下比如设定maxDistancePerFrame 0.05f再用循环插值移动到目标位置。5.2 帧率越高跑得越快漏乘 deltaTime现象同样的速度值在 144Hz 显示器上移动速度是 60Hz 的 2.4 倍在 Editor 里有时快有时慢。原因Update的调用频率与帧率绑定每帧位移如果不乘Time.deltaTime实际移动速度就是“帧率 × 速度”帧率越高跑得越快。解决所有基于Update的移动都乘以Time.deltaTime。检查方式很简单切到 Game 视图打开 Stats 面板观看帧率再移动物体如果不同帧率下移动速度不同检查你的位移代码有没有漏乘。这个坑几乎每个 Unity 开发者都踩过最有效的防止办法是移动代码里永远不要写裸的speed一律speed * Time.deltaTime形成肌肉记忆。5.3 新输入系统激活后旧代码全部失灵现象项目升级、新建场景或移动平台打包之后原有的Input.GetAxisRaw代码不再返回任何输入值控制台没有红字但按键毫无反应。原因Unity 在 2019.2 之后引入新输入系统新版项目或手动切换了Active Input Handling后旧的Input Manager被禁用Input.GetAxis系列 API 要么抛异常、要么返回默认的 0。解决进入Edit Project Settings Player Active Input Handling改为Both模式兼容两套系统。注意 Unity 2023 之后的某些模板项目会直接默认只有新系统改成Both后建议快速重启一次 Editor 让输入后端重新初始化。如果项目计划长期维护尽早把移动脚本迁移到InputAction的回调结构不要长期依赖兼容层。5.4 摄像机跟随导致的移动方向错乱现象角色按 W 前进时画面里角色不走直线走着走着会斜向漂移转动摄像机之后按 W 更是朝着跟镜头完全无关的方向移动。原因移动方向用了世界坐标比如Vector3.forward但场景里摄像机视角是倾斜的玩家天然认为“按 W 向屏幕深处走”。当摄像机从正面向侧方移动时输入方向与视觉方向不一致就出现“斜着走”的错觉。解决改用相机方向换算输入第三节里的GetCameraRelativeDirection可以直接解决。把这个函数放在移动脚本里复用。如果项目里一直没有MainCamera一定先从场景里确认摄像机标签设置我把这一个坑的排查排在好多大需求前面因为它一错整个角色手感全完蛋。5.5 刚体直接改 Transform 导致物理引擎失效现象挂载Rigidbody的物体用transform.position ...移动物体看起来动了但撞到别的物体时完全不响应碰撞或者被撞飞后位置突然跳回。原因物理引擎内部维护刚体的位置状态外部直接写transform.position会让内部状态和新位置脱节碰撞检测和受力结算都基于旧的内部位置。解决有Rigidbody的物体一律通过rb.MovePosition、rb.velocity或rb.AddForce驱动。MovePosition每帧调用也会在物理步进时进行插值适合需要“外力参与”的平滑移动。另一点默认好习惯是刚体移动逻辑全部放FixedUpdate输入读取放Update两个循环各司其职物理才稳定。6. 验证移动手感的小技巧与调试习惯移动代码写完不代表完事我更信“画出来”而不是“感觉对”。先给移动方向画一条可视化的线void OnDrawGizmos() { if (Application.isPlaying) { Vector3 dir new Vector3(Input.GetAxisRaw(Horizontal), 0f, Input.GetAxisRaw(Vertical)).normalized; Debug.DrawRay(transform.position, dir * 2f, Color.green); } }在 Scene 视图里按下 Play观察绿线的方向和长度绿线应该始终指向你按的键对应的世界或相机方向、长度恒定。如果斜向走动时绿线比直线长说明normalized没生效如果绿线方向跟角色实际移动方向不一致说明坐标系换算出了问题。这个技巧比肉眼看屏幕判断“手感不对”靠谱得多能让方向类问题一秒钟暴露。验证速度是否正确的另一个习惯是在代码里记录上一帧位置计算实际位移private Vector3 lastPos; void Update() { Vector3 currentPos transform.position; float actualSpeed (currentPos - lastPos).magnitude / Time.deltaTime; Debug.Log($实际速度: {actualSpeed:F2} m/s); lastPos currentPos; }这里打印出来的值应该约等于你在 Inspector 里设置的moveSpeed。如果偏差超过 10%要么撞到了障碍物、要么方向向量长度有问题、要么deltaTime使用不当。我通常会在移动系统调试阶段保留这个输出等速度稳定后再删掉否则控制台打印本身也有轻微的性能开销。最后想提一个经常被人忽略的细节Time.timeScale会影响Time.deltaTime——你如果做了暂停菜单或者慢动作特效用Time.deltaTime的移动代码会跟着暂停或减速。这是预期行为但如果你想做那种“暂停时 UI 还在飘动”的效果需要改用Time.unscaledDeltaTime。这也是移动代码里最容易被全局机制牵连的暗坑排查半天还以为是移动逻辑写错了。我现在写移动代码第一件事就是定“这套物体要不要被物理推着走”绝不用Transform直改糊弄过去写完速度系数后永远跑一遍“三秒位移验证”再画一条方向线看一眼。这些习惯帮我避开过太多排队式的 debug 时间希望也能帮到你少走点弯路。本文还有配套的精品资源点击获取