Unity第一人称控制器：CharacterController移动、跳跃与手感调优

刚进入Unity世界做第一人称控制的时候，我第一反应是“这不就是个移动脚本吗”，但真正把一个角色的移动、旋转、重力、碰撞、跳跃拼在一起后才发现，FPS手感这件事远不止“按W往前走”这么简单。花了整整一个周末踩坑、打磨、重写之后，我决定把一套相对完整的第一人称视角人物控制方案整理出来。

这套方案适合刚做完Unity基础教程、准备从“能动的方块”跨到“能玩的角色”阶段的开发者，也适合已经用Rigidbody做过物理移动、却发现手感怪怪的半路玩家。它解决的核心问题很直接：如何用CharacterController实现一套响应迅速、不穿墙、不漂移、跳跃自然的第一人称控制，并且解释清楚每一步“为什么这么做”。读完你不仅能直接抄一套可用代码，还能搞懂背后选型的原因和调手的思路。

1. 整体设计思路：方案选型比写代码更重要

1.1 三种移动方案横向对比

做第一人称移动，Unity里从来没真正少过方案。我周围不少朋友一开始都会纠结用哪种。现阶段常见的其实是三条路：直接改Transform、用Rigidbody、用CharacterController。

直接改Transform最简单，像是把角色放在一个立方体上，然后每帧根据输入往目标方向加位置。好处是代码短、响应零延迟，几乎没有引擎层面的“制动”，但坏处非常致命：第一，Transform移动默认不参与物理碰撞，除非你之后写射线检测和碰撞反应，否则就是一路穿墙，把墙当成不存在，这对FPS来说是闹剧；第二，它不受重力影响，你必须自己去算g、去处理落到地面的情况，等于把物理引擎的主要功能全部手动实现一遍。我的结论是：如果不是在写纯原型demo，不推荐拿它做基础移动。

Rigidbody方案则相反，引擎帮你管物理，移动时给速度、给力，角色穿过刚性物体时会被物理系统拦住。看似省心，但FPS场景里Rigidbody有几处非常费劲：一是反馈存在延迟，你是给物理引擎下达“速度目标”，引擎再通过刚体模拟逐步逼近，手感上天然多一层“软”；二是摩擦力和惯性难控制，你在冰面上、草皮上、空气中用同一套参数，手感很可能不同；三是穿透问题依然存在，高速移动时刚体照样可能跳过薄的碰撞体，最后你还是得开Continuous碰撞模式，那种模式对性能消耗不小。

CharacterController是一条中间路线。它不是刚体，不会参与物理模拟，但它与场景中的Collider产生有限制的碰撞，能阻止你穿墙，也能给出isGrounded判断。它没有质量、没有力、没有摩擦概念，位移全部由你的代码控制，这意味着你拥有最高程度的“手感调度权”。代价是你得自己处理重力和跳跃，可这通常是好事。FPS玩家要的就是“按一下立刻响应”的直觉感，而不是模拟真实惯性，CharacterController天然适合这种诉求。

1.2 我最终选型：CharacterController + 自研重力

我最终选择了CharacterController加自己写的重力逻辑，准确说是一套基于“速度-重力叠加”的移动方案。核心思路是：角色有一个竖直方向速度velocity.y，每一帧给它叠加重力加速度，然后用CharacterController.Move()来执行实际位移。CharacterController处理与地面的碰撞、斜坡坡度限制、台阶判定，重力则由我自己控制手感。

这套组合的好处在于“一半靠引擎、一半自己来”。引擎负责最让人头疼的碰撞边界，你负责最能决定体验的加速度和重力曲线。控制思路也清晰：水平方向的移动是瞬时响应还是逐渐加速，由你决定；竖直方向每一帧根据当前速度和重力刷新，落地时归零。很多教程会把重力写成velocity.y += Physics.gravity.y * Time.deltaTime，这没错，但我之后在实际项目中更喜欢用一个可调参数gravity替代默认值，因为FPS中“重力感”太强或太弱都会让跳跃手感崩掉，默认-9.81经常不够或太过。

选型这件事也带来了一个非常现实的收益：项目后续如果加入交互物品、物理碰撞、可移动箱子，CharacterController脚本本身不用改，你做的只是给物品添加Rigidbody和Collider，让它们存在就好，玩家的底盘稳如泰山。所以如果你还在犹豫，我的经验是：对于FPS角色本体，CharacterController始终是性价比最高的起点。

2. 第一人称控制的核心骨架：输入与移动

2.1 输入映射与鼠标锁定

开始写代码前，先处理两件容易漏的小事：鼠标要锁定到屏幕中央并且隐藏可见光标，输入轴要确认Horizontal/Vertical映射正常。

鼠标锁定的代码通常在Start或者玩家按下ESC后处理。锁定后，系统会隐藏鼠标并且把指针固定在窗口中心，这保证视野旋转时不会让鼠标撞到窗框或超出边界。游戏中玩家按Esc之后建议释放锁定并让菜单堂而皇之弹出来，此时再写一个暂停输入的逻辑。我在实现里用了最直接的写法：

Cursor.lockState = CursorLockMode.Locked; Cursor.visible = false;

如果你用的是Unity新输入系统（Input System Package），经典的Input.GetAxis已经失效了。旧系统的输入轴依赖Project Settings里的Input Manager，如果你的项目在创建时选择了新的Player Input方案，代码里调用的Input.GetAxis("Mouse X")会报错。我建议新手先用老系统跑通思路，熟悉之后再迁移到新版Input System。另外记得在Edit > Project Settings > Input Manager里确认Horizontal和Vertical映射的是WASD和方向键。

2.2 位移代码的最小实现

第一人称位移的最小实现，其实核心只有三步：读取输入轴、基于角色前方和右方向组合成移动向量、调用CharacterController.Move。请直接看这段标准代码：

float horizontal = Input.GetAxis("Horizontal"); float vertical = Input.GetAxis("Vertical"); Vector3 move = transform.right * horizontal + transform.forward * vertical; controller.Move(move * speed * Time.deltaTime);

解读一下：transform.right是角色当前面向的右方向，transform.forward是角色当前面向的前方向，我们要的是“相对于角色朝向的移动”，而不是“世界坐标的WASD移动”。如果直接用Vector3(horizontal, 0, vertical)，角色往前跑时按W确实向前，但你转身面向左边时再按W，就会发现自己仍往世界坐标的Z轴方向前进，角色永远不会拐弯。正确写法就是上面的组合，它会随着角色旋转而动态改变移动方向。

有一点要注意：Move()里要把move乘上Time.deltaTime，因为Move的入参是“这一帧要走多远”，而不是速度。如果你不乘deltaTime，速度会随帧率变化，60帧下角色快得离谱，30帧下又慢得让人抓狂。deltaTime这个家伙几乎出现在所有运动代码里，忘掉它等于把性能交给了运气。

2.3 旋转机制：人物转Y轴，相机转X轴

第一人称旋转是新手最爱写错的地方。正确姿势是这样的：鼠标横向移动（Mouse X）旋转整个玩家的Y轴（偏航角），让角色身体转向；鼠标纵向移动（Mouse Y）旋转相机的本地X轴（俯仰角），让视野抬头低头。理论上也可以用一块主相机跟随旋转整个玩家，但那样会把相机的俯仰也算进角色旋转，先不说旋转矩阵复杂，你会发现角色走着走着就躺下了，物理碰撞判定全部乱套。

具体写法是：

float mouseX = Input.GetAxis("Mouse X") * mouseSensitivity; float mouseY = Input.GetAxis("Mouse Y") * mouseSensitivity; xRotation -= mouseY; xRotation = Mathf.Clamp(xRotation, -90f, 90f); cameraTransform.localRotation = Quaternion.Euler(xRotation, 0f, 0f); transform.Rotate(Vector3.up * mouseX);

xRotation负责纵向趴下抬头，限制在-90到90度之间，防止你像猫头鹰一样把脑袋转到背后；transform.Rotate(Vector3.up * mouseX)负责左右转身。为什么mouseY是负累减？因为在Unity里鼠标向上移动时Mouse Y是正数，但抬头应该是朝正X轴旋转，而Quaternion.Euler的角度里正X旋转实际是向下低头。所以记录时我们反着减，同时旋转时再传入Euler的第一项。这里记得cameraTransform应该指向挂在玩家子节点下的主摄像机Transform，别把相机挂到场景里的任何外部节点上。

这套旋转逻辑加进Update更新之后，你会发现鼠标横移的时候视角顺滑地让世界在你面前转，鼠标纵移的时候视角会根据你的操作抬头低头。第一阶段的核心骨架就搭完了：你能走、能转身、能抬头，剩下的就是让它更好用。

3. 重力、跳跃与碰撞的处理细节

3.1 重力模拟与isGrounded判断

CharacterController自带一个isGrounded属性，但它什么时候为真、什么时候为假，取决于你已经执行过多少帧Move。它的工作原理是根据胶囊体底部的碰撞检测结果来判断。这里有个关键的坑：很多教程把这句丢进Update开头，然后立刻执行Move，第一次执行前isGrounded永远是false，导致玩家飘在空中一秒才落地。

我的做法是先把isGrounded缓存到自己的变量里，并且在Update内主动判断竖直速度：如果落地且竖直速度小于0，就把竖直速度压到一个接近0但不等于0的值，比如-2f。这能避免玩家每帧都在“地面-微离地-落地-再落地”之间抖动。代码：

isGrounded = controller.isGrounded; if (isGrounded && velocity.y < 0) { velocity.y = -2f; }

这个-2f不是0，因为如果设为0，超过极限的下坡速度可能不会触发下一步的isGrounded更新，偶尔会出现角色一跳一跳的抖动。压到负数可以保证下一帧仍然保持地面接触姿态，不至于让重力重新“拉起”角色。这算是个实战里的隐性细节，不少人在以后的车轮式跳跃或上下坡场景会因为这个撞墙。

3.2 跳跃高度是如何换算的

跳跃逻辑很长一段时间里都是大家照着别的项目抄的，但很少人知道jumpHeight参数和重力值怎么换算成合理的初始向上速度。我们需要让跳跃高度与重力决定的时间成二次方程关系。假设重力加速度为g向下，跳跃初速为v0向上，最大高度h = v0^2 / (2g)。所以当你想让玩家跳到1.2米高，重力取-9.81，那么初速度应该是：

velocity.y = Mathf.Sqrt(jumpHeight * -2f * gravity);

这个公式本质上就是把二次运动的最高点公式反推。如果重力是-9.81，想要1.2米高，那初速度约4.85米/秒。很多教程硬给velocity.y = 5f，效果看起来还行，但那是因为他们碰巧猜对了参数。用公式的好处是，你改jumpHeight后系统自动换算成合适的初速，不会出现跳得跟升空火箭一样的情况。

跳跃触发条件必须包括“按下跳跃键”和“站在地面”两个条件。按下检测我用Input.GetButtonDown("Jump")，它只在按键落下的那一帧返回true，不会像GetKey一样持续触发连跳。条件都满足后，把Mathf.Sqrt(jumpHeight * -2f * gravity)赋给velocity.y。

3.3 斜坡、台阶与碰撞头尾

CharacterController对斜坡和台阶有内置处理机制。默认的Slope Limit是45度，这代表角色能在不大于45度的坡面上站住并走上去，超过这个角度的坡会被当墙处理。Step Offset默认值在0.1到0.5之间，它决定了角色能一格一格迈上台阶的最大高度。第一人称里我倾向于把Step Offset保持0.3到0.4，太小会卡在矮路沿上，太大会产生“瞬移上台阶”的飘浮感。

斜坡上有个很坑的现象：角色站在坡面上时，因为重力沿斜面方向的分量会让角色缓慢滑下来。如果你不希望角色在斜坡上像个被推倒的人偶，需要自己对velocity.y和水平分量做补偿，或者干脆限制角色只能在平地跳跃。最稳妥的做法是增加一个“在斜坡上禁止跳跃”的判断：先计算法线方向，如果坡面与水平面的夹角大于某个阈值，就跳过跳跃。可以在Update里获得地面法线：

if (controller.isGrounded) { // 利用Physics.Raycast在脚下发射一条短射线获取法线，然后判断是否允许跳跃 }

这部分我是用一条从角色底部中心向下发射0.2米左右的射线做的，命中后读取hit.normal，再用Vector3.Angle(hit.normal, Vector3.up)判断角度。超过阈值时禁止起跳，并给水平移动一点点顺坡分量。否则玩家在40度山坡上按空格，会跳出去一整个山坡那么远，那感觉完全不像FPS。

4. 手感调优：从“能跑”到“像FPS”

4.1 移动加速度与阻尼

当前位置移动速度是指数逼近的平滑模式，而不是瞬发。FPS里如果速度从0直接拉满，看起来像纸片人在滑行，缺少“由静止起步”的重量感。但过度平滑又会让操控响应变慢，那种粘滞手感在瞄准对枪时非常吃瘪。标准FPS手感的折中方案是：地面移动时用一个很快的Lerp让速度逼近目标，空中时则允许速度更快变化。

我通常把移动更新写成这样：

Vector3 targetVelocity = move * speed; currentVelocity = Vector3.Lerp(currentVelocity, targetVelocity, moveSmooth * Time.deltaTime); controller.Move(currentVelocity * Time.deltaTime);

moveSmooth参数在10到15之间比较合适，小于5会有明显的“拖泥带水”，大于20其实和瞬间加满了没区别。也可以用Vector3.MoveTowards来做匀速逼近，但Lerp在帧率稳定时更自然，也更省计算。

空中控制又是一个独立话题。第一人称射击里如果空中能改变方向，玩家会觉得轻飘飘；如果完全不能变向，又有“落地之前变成僵尸”的挫败感。我喜欢把空中加速度压缩到地面的一半甚至更低，实现时很简单，只要在计算targetVelocity时检测地面状态，不在地面就把加速度乘个0.4。

4.2 鼠标灵敏度与旋转上限

鼠标灵敏度这块，直接乘以mouseSensitivity确实能做，但不同屏幕分辨率、不同DPI、不同操作系统下的同一数值，实际手感差异极大。我习惯给灵敏度加一个基于分辨率比例的修正系数：灵敏度乘以(Screen.height / 1080f)，这样在4K屏上不会慢到像拖动老牛车，在1080p小窗口也不会转得跟抽风一样。当然这只是经验值，你也可以根据自己鼠标习惯再乘调整。

纵向视角的Clamp范围，默认-90到90度是一种理论值，但实际战斗里没人爱把头仰到垂直天空或完全低头看裤裆。我推荐把俯仰范围收紧到-85到85度，留出一点边际能避免视野翻转的怪异感，也可以防止相机角度恰好卡在正上正下时四元数的万向锁问题。

另外，Mouse X轴与Mouse Y轴最好分开微调，很多外设的纵向移动和横向移动手感本来就不同，如果你一套灵敏度两个方向通吃，会有一种“上下慢、左右快”或相反的不协调感。我把横向灵敏度和纵向灵敏度拆开成两个可调值，实际测试后大概横向比纵向大20%左右比较自然。

4.3 头部晃动与摄像机细节

单纯的移动和旋转已经能让角色跑起来，但要达到FPS“有灵魂”的手感，还得处理摄像机的细节。FPS摄像机最忌两件事：一是不要把摄像机直接挂到CharacterController底部的空物体上，然后让该物体跟着controller.Move稍微抖动，这样会造成一种名为“减速带效应”的画面颤抖；二是不要给摄像机挂Rigidbody，更不该让相机去参与物理结算。

我的做法是：玩家空物体挂CharacterController和角色控制器脚本；玩家空物体下挂一个CameraHolder空物体，摄像机挂在CameraHolder下面。CameraHolder的位置永远等于玩家头部位置，可以在Update里把它直接设到眼睛所在高度，比如(0, eyeHeight, 0)，然后摄像机本身再处理俯仰旋转。头部高度大概1.6到1.7米比较合理，太矮像蹲着跑，太高像踩着高跷。

如果要加一点走路时的自然晃动，可以用正弦函数给x和z方向叠加非常小的偏移，幅度控制在0.02到0.05之间，频率跟着移动速度走。这样能给玩家“自己在走”的暗示，又不至于让瞄准准星乱抖。这个晃动参数我建议用Mathf.Sin(Time.time * walkFrequency) * walkBobAmount来控制，并且在代码里允许调小或关闭，因为并不是每个FPS项目都需要这种效果。

4.4 跑步、冲刺与体力消耗扩展

基础的Walking速度大概4到5米/秒，FPS里普遍偏慢；冲刺速度设为8到9米/秒比较有力度感。我在代码里用Input.GetKey(KeyCode.LeftShift)来切换速度，但立刻切会有突然加速的冲击感。更自然的方式是把当前速度Lerp向目标速度，不要直接赋值。

体力系统是很多FPS都有的机制，但Unity初学阶段直接加体力会增加一堆状态管理，我建议第一阶段只做“松开Shift回到走路速度”，甚至不设体力，先把移动底盘控制稳定。等想强化手感时，再引入体力消耗和恢复。如果一定要现在做，就简单计时：冲刺时每秒减固定耐力，耐力归零后禁用冲刺，松开恢复即可，这一整套逻辑不影响核心移动，属于锦上添花。

5. 完整代码与场景搭建实录

5.1 场景搭建步骤

搭建测试场景很简单，但有几个细节能保证后面的调试不抓狂：地面用一个Plane或Cube放大平铺，四周围几面垂直的墙，中间摆几个平行六面体作为障碍物。地面必须无损且无缝隙，否则角色会从两块Plane的接缝掉下去。墙和Cube不用加Rigidbody，只要带Collider即可，CharacterController与它们碰撞不需要对方是刚体。

场景里一定要放一盏Directional Light，否则环境全黑，新手会误以为摄像机坏了。然后在场景里Create Empty命名为Player，给Player挂Capsule Collider（如果你不放CharacterController组件它会提示自动添加），再添加CharacterController组件，设置高度为2、半径为0.5、Center为(0, 1, 0)，让胶囊体底边恰好贴地面。接着建一个Camera作为Player的子物体，位置设为(0, 1.6, 0)，清空旋转。这里的Camera就是之前代码里要取的相机Transform。

如果你希望相机覆盖全屏并稳定FOV，记得在相机Inspector里把FOV调到60-90之间，这影响视距压迫感，与手感无关但和视觉舒适度强相关。

5.2 完整脚本与参数表

下面是整理后的完整FPS控制脚本，基于旧的Input Manager编写，可以直接挂到Player空物体上：

using UnityEngine; public class FPSCameraController : MonoBehaviour { [Header("组件引用")] public CharacterController controller; public Transform cameraTransform; [Header("移动参数")] public float walkSpeed = 4f; public float sprintSpeed = 8f; public float jumpHeight = 1.2f; public float gravity = -9.81f; [Range(1f, 30f)] public float moveSmooth = 12f; [Range(0f, 0.5f)] public float airControlFactor = 0.4f; [Header("视角参数")] public float mouseSensitivityX = 2f; public float mouseSensitivityY = 1.6f; public float minPitch = -85f; public float maxPitch = 85f; private float currentPitch; private Vector3 currentVelocity; private Vector3 verticalVelocity; private bool isGrounded; void Start() { if (controller == null) controller = GetComponent<CharacterController>(); if (cameraTransform == null) cameraTransform = GetComponentInChildren<Camera>().transform; Cursor.lockState = CursorLockMode.Locked; Cursor.visible = false; } void Update() { HandleLook(); HandleMove(); HandleJump(); ApplyGravity(); } void HandleLook() { float mouseX = Input.GetAxis("Mouse X") * mouseSensitivityX; float mouseY = Input.GetAxis("Mouse Y") * mouseSensitivityY; currentPitch = Mathf.Clamp(currentPitch - mouseY, minPitch, maxPitch); cameraTransform.localRotation = Quaternion.Euler(currentPitch, 0f, 0f); transform.Rotate(Vector3.up * mouseX); } void HandleMove() { bool isSprinting = Input.GetKey(KeyCode.LeftShift); float currentTargetSpeed = isSprinting ? sprintSpeed : walkSpeed; float horizontal = Input.GetAxis("Horizontal"); float vertical = Input.GetAxis("Vertical"); Vector3 inputDirection = transform.right * horizontal + transform.forward * vertical; if (inputDirection.sqrMagnitude > 1f) inputDirection.Normalize(); float smooth = isGrounded ? moveSmooth : moveSmooth * airControlFactor; currentVelocity = Vector3.Lerp(currentVelocity, inputDirection * currentTargetSpeed, smooth * Time.deltaTime); controller.Move(currentVelocity * Time.deltaTime); } void HandleJump() { if (Input.GetButtonDown("Jump") && isGrounded) { verticalVelocity.y = Mathf.Sqrt(jumpHeight * -2f * gravity); } } void ApplyGravity() { isGrounded = controller.isGrounded; if (isGrounded && verticalVelocity.y < 0) verticalVelocity.y = -2f; verticalVelocity.y += gravity * Time.deltaTime; controller.Move(verticalVelocity * Time.deltaTime); } }

这段脚本把移动、旋转、跳跃、重力都整合到一块，参数全部暴露在Inspector面板里，方便看出不同参数对手感的具体影响。几个地方值得特别说明：移动输入方向先归一化，否则斜向移动会比直线移动快约1.414倍，这算是Graphics算法新人最常犯的向量方向错误；空中控制因子直接乘在平滑系数上，让空中变向感降低；verticalVelocity单独用一个Vector3，可以和水平速度分开存储。

参数的参考初始值我整理成了下表，方便照抄或校准：

5.3 可选扩展：蹲伏与冲刺

蹲伏看起来和移动控制关系不大，却是FPS常见需求。最基础的做法是：按下Ctrl时把CharacterController的高度和Center改小，把相机局部位置降低。但直接改高度会带来两个坑：一是蹲下时胶囊体高度缩短后，模型可能瞬间悬空；二是蹲下时有很高概率离开地面，角色会滑出去一截。

我的处理方式是给脚本增加一个bool isCrouching，在Update开始处用Input.GetKey(KeyCode.LeftControl)更新，然后根据状态缓存/还原控制器高度和相机高度。转换过程不要一帧到位，用Lerp做平滑需要大概0.1秒。更稳妥的做法是蹲伏前先把胶囊体的底部Y坐标固定在地面附近，Center的Y也同时下移，保证胶囊体底部不动，只有顶部下沉。这块后续如果引入真正的环境交互、UI菜单再扩展也不迟。

6. 常见问题与排查技巧实录

6.1 移动时视角抖动

这个问题我在调优阶段遇到过太多次。现象是角色边移动边旋转的时候，画面会像隔着一层果冻一样抖。原因通常有几个：一，移动和旋转都跑在Update里，但如果你的相机是挂在物理刚体上，物理引擎会把相机位置强行掰到FixedUpdate的节奏上，两套时间轴打架，画面自然抖动，解决方案就是本文前面提到的相机不挂物理刚体；二，移动代码把Time.deltaTime换成了Time.unscaledDeltaTime叠加，导致在时间缩放不正常时位移量失真；三，移动平滑参数太小，速度Lerp追踪不够快，在帧率波动的时候会产生轻微卡顿感。排查时先把相机下所有额外组件移除，再看移动平滑，最后检查输入轴是否有异常平滑。

6.2 角色穿墙或卡在墙角里

CharacterController的碰撞不是万能的，尤其是高速移动的时候。默认的检测方式在低速下没问题，但如果冲刺速度过高、或当帧的位移量大于碰撞体厚度且移动向量斜向穿过墙角，就会发生轻微陷入。解决思路有几个：把速度阈值限制在合理范围，比如冲刺不要超过9米/秒；移动方向做“切墙处理”而不是直接保留原始方向，也就是碰撞之后让角色贴着墙滑动，这在实际项目中经常叫“滑墙”，可以用controller.Move后检测碰撞信息并修正剩余位移。卡墙角现象则是碰撞后角色被对角的多面碰撞体夹住，每帧都左右撞击。我的经验是给角色增加一个向脚尖方向发射的短射线，如果射线被撞，就禁止继续沿该方向位移，这个处理对绝大多数墙角都有效。

6.3 跳跃失灵或跳一下就再也跳不起来

新手最容易踩的坑是被Ground判断误导。CharacterController.isGrounded只有在执行Move之后才更新，而某些版本会延迟一帧才刷新状态。当你快速连续按两次Jump时，第一次跳跃后isGrounded还保持true，垂直初始化正常；第二次按下时虽然已经腾空但isGrounded还没来得及变为false，就会在空中再次起跳。反过来，如果角色刚落地就按跳，落地帧isGrounded可能还是false，造成明明按了却毫无反应。解决方法是加入一个地面锁定计时器：落地后允许0.1秒内的跳跃输入，即使isGrounded还没完全确认。同时，在ApplyGravity里我已经把落地速度压到-2f，这会让isGrounded在下一帧更可靠地更新。另外一个很蠢的错误是忘了在Inspector里给角色加CharacterController，脚本里的GetComponent拿不到组件，所有Move都会报NullReference。

6.4 转身时角色歪向一边或准星漂移

这种情况几乎都是旋转代码把俯仰角加到角色自身旋转而不是相机上导致的。如果你发现角色转头的瞬间整个世界倾倒了，检查是不是把Quaternion.Euler(currentPitch, yaw, 0f)直接赋给了玩家Transform。正确做法是左右转身只动玩家Y轴，上下抬头只动相机X轴。可能还有另一种情况：相机没挂在Player子物体下，而挂到了场景独立物体，旋转时相机围绕世界坐标旋转，看起来自然就会“歪”。把相机作为Player子物体并且位置清零后基本能解决。

6.5 不同分辨率下手感突变

很多人在自己电脑上调试好好的，到笔记本上一跑发现鼠标转动快得像陀螺，或者屏幕越大转得越慢。这大概率是因为不同显示器缩放比例不同，Unity的Screen.height与物理DPI有关，但输入采样上是像素级别。我的修复办法是上面提到的“以1080p为基准的高度比例缩放灵敏度”，并且在发布游戏时设计一个灵敏度菜单。这是一个实操里绕不开的老问题，先加到设置里总归能用。

6.6 落地时滑一脚或下坡砸进地面

落地滑一脚主要是因为落地帧时verticalVelocity.y被清零后，水平移动速度还残存着之前运动状态叠加出的倾斜分量。下坡时CharacterController自带的重力响应会让角色像坐滑梯一样加速，这在地形复杂的FPS里很常见。你可以在地面状态下把verticalVelocity.y压到-2f，同时把下坡时过高的水平位移，通过检测地面法线做一个投影修正，将移动平面拉回沿坡面方向。核心思路是：你不能只处理世界Y轴，而要根据脚底法线重新定义“地面平面”。

7. 手感打磨之外：我留下的几个经验习惯

这套FPS控制我从零搭建到反复打磨，前后试了三天。最后分享一点比较个人化的体会：控制脚本的每个参数都应该做成一目了然的Inspector字段，而且一定要有合理的默认值。这样当你接手另一个项目或别人拿着一套参数来问你“为什么我的速度这么漂”的时候，你可以在编辑器里一句话不说，挨个滑杆拖一遍直接把手感调出来。很多人写移动脚本就是两三个硬编码常量堆在一起，最后调参改代码改到心力交瘁，我吃过这个亏之后再也不做这种事。

另一个习惯是：每一套核心控制代码我都会配上至少一段注释，写明“这里的-2f是为了防止isGrounded误判抖动”，而不是写一堆毫无信息量的“// 移动玩家”。这些当年用热血写的注释，三个月后看就是救命稻草，尤其当你发现某个跳跃Bug时，翻到注释直接知道当初为什么这么做。

最后，如果你准备加入射击、交互、敌人AI等功能，请记住角色控制脚本只负责移动和视角，不要把开枪、开火、生命值、HUD混进来。保持单一职责能让你后期维护时身心愉悦。这套可复制的FPS控制器我后续也打算补充蹲伏、冲刺耐力、坡面专用移动分支等模块，但核心就是前面这些基础，把它们吃透，你已经超过了大多数只抄代码不求甚解的Unity初学者一大截。