从键盘控制小球到XR交互：Unity输入系统与物理运动核心解析

1. 项目思路拆解：键盘控制小球背后藏着XR交互的地基

先把这个项目掰开揉碎说清楚。标题是"与玩家交互——用键盘控制小球移动"，看起来是个再基础不过的入门练手，但真正在XR（扩展现实）开发里摸爬滚打过的人都知道，这一步远不是"让小球动起来"那么简单。

XR开发的特殊性在于硬件依赖重、交互链路长。你写了一个移动逻辑，在PC上跑得好好的，一到头显里就各种问题：手柄映射不对、坐标系错乱、延迟超标。这些问题的根子往往不在设备本身，而在早期的交互抽象层没做好。键盘控制小球恰恰是把这个抽象层练扎实的最好方式——它把一个"玩家意图转换为虚拟物体运动"的完整闭环跑通了，只是输入源从手柄换成了键盘。

这个项目的核心价值可以拆成三层：

• 第一层：实现基本按键监听，让小球响应键盘输入，完成位移。
• 第二层：把"输入"和"运动"解耦——不管按的是键盘WASD还是手柄摇杆，底层移动逻辑都一样。
• 第三层：按照XR设备的输入规范做映射预留，后续接入真实VR/MR设备时，只换输入源，不重写移动逻辑。

我见过太多人跳过第二层、第三层，直接在Update里写transform.position += new Vector3(Input.GetAxis("Horizontal"), 0, 0)，做完感觉良好。等到后面要接Oculus Touch或者HoloLens手势时，整个控制代码全得推翻重来。这就是没理解这个项目真正要训练的东西。

适合把这个项目吃透的朋友，是那些刚接触XR开发、对交互设计还没有形成系统感觉的初学者，以及已经在做Unity/Unreal开发但想迁移到XR方向的工程师。这属于XR开发系列的基础篇，但恰恰是"基础"里最能看出功力的部分。

2. 技术方案选型：为什么是Unity + 输入系统抽象层

2.1 引擎选择：Unity仍是XR交互开发的最优解

做XR开发，引擎选择基本在Unity和Unreal之间二选一。这个项目选Unity，理由很实在：XR Interaction Toolkit（XRI）在Unity 2021.3 LTS之后已经进入成熟期，官方对OpenXR标准的支持非常完整，从Quest、Pico这类一体机到PC VR头显、MR头显，一套接口通吃。而且Unity的编辑器迭代效率高，写键盘模拟交互逻辑时，编辑器里直接跑、直接调试，不需要每次都戴着头显反复摘戴。

如果你用Unreal，不是不行，但蓝图和C++的配对对这个体量的项目来说偏重。键盘控制小球这种基础场景，Unity的MonoBehaviour生命周期配合物理系统（PhysX）就能轻松搞定，迭代节奏快得多。

2.2 输入系统选型：新版Input System是唯一正确选择

这里我要明确一个观点：不要再用旧的Input Manager（即Input.GetAxis那套），直接上新版Input System Package。理由有三点：

1. 跨设备输入统一：新版Input System天然支持键盘、鼠标、手柄、XR控制器等多种设备，通过Action Map自动切换。你写的是键盘控制，但映射到XR手柄摇杆时，只需要改配置，不用改代码。
2. 延迟和精准度更好：它基于事件驱动，不像旧版按帧轮询，对高精度交互（比如XR中的抓取、瞄准）友好得多。
3. 官方推荐且长期维护：Unity已经明确新功能只在新Input System上迭代，旧版只是兼容性保留。你现在学旧版，等于在给未来挖坑。

具体到这个项目，我会用Input System的Action回调方式而不是直接轮询按键状态。原因后面展开，先记住这个结论就行。

2.3 核心设计思路：定位、移动、交互三层分离

这个小项目最容易写坏的地方，就是所有逻辑全塞在一个脚本里。我见过一些教程，一个MoveBall.cs里既处理输入、又做物理移动、还顺带改了小球的颜色和材质，看起来功能全，实际一坨浆糊。后面你想给小球加跳跃、加冲刺、换输入设备，全都得动这个脚本，改一处崩三处。

我的做法是严格分三层：

• 输入层：负责监听设备输入，转换成玩家意图。键盘按下"W"或摇杆前推，统一翻译成"前进方向+速度强度"。这一层只产出抽象数据，不关心数据给谁。
• 逻辑层（玩家驱动接口）：定义移动的接口规范，比如"以什么速度往哪个方向移动"。这一层不关心输入来自键盘还是手柄，只定义"游戏对象应该如何响应"。
• 表现层（运动控制）：具体操作小球刚体，让它加速、减速、转向。这一层不关心玩家按了什么键，只接收逻辑层的指令。

这三层之间用接口或者事件通信，彼此不直接依赖。这样设计的好处非常明显：键盘和手柄只是输入层的不同实现，逻辑层和表现层完全不用感知输入源的变化。

2.4 参数设计：物理运动必须先算清楚再写代码

不少文章直接把移动速度设为5f就完事了，但实际物理参数应该是从场景尺寸推导出来的。假设我们的小球半径是0.5米，场景平面是10×10米，要让玩家感觉"合适"，小球应该在1~2秒内横穿半个场景。5米路程除以1.5秒，速度大约是3.3米/秒，取整设为3.5f比较合理。

物理材质方面，地面设置动态摩擦力0.4，静态摩擦力0.6，让小球能被推动但不会一碰就滑出去；小球自身设置0.1的摩擦力，减少滚动时的能量损耗。这些参数不是随便写的，它们对应的是"手感"——太快了玩家控制不住，太慢了感觉又闷又笨。

这个项目里刚体用的移动策略也值得你想清楚：transform.position直接改位置不是不行，但会绕过物理引擎，碰撞和滚动效果都会失真。正确做法是操作Rigidbody的velocity，把速度和方向算好后交给物理引擎，这样才能得到真实的碰撞反馈和滚动效果。这也是XR交互里常说的"让物理引擎做它该做的事"。

3. 核心交互逻辑实现：从键盘到小球运动的完整路径

3.1 环境准备与工程配置

实操从头开始。先创建一个3D项目（Unity 2022.3 LTS或更新版本），然后按下面步骤配置：

第一步，安装Input System Package。 在Window -> Package Manager中搜索Input System，点击Install。安装完成后会弹窗提示需要重启编辑器并启用新输入后端，激活后编辑器会重启。如果没有弹窗，可以到Player Settings -> Active Input Handling里手动改成"Input System Package (New)"或"Both"。

第二步，创建Input Actions资源。 在Project窗口右键 -> Create -> Input Actions，命名为PlayerControls。双击打开配置面板，默认会有一个"Player"Action Map，这里我们需要给Player映射添加两个Action：

• Move：Action Type设为Value，Control Type设为Vector2。这对应键盘WASD的二维方向输入。
• Jump：Action Type设为Button。这对应空格跳跃（虽然是进阶功能，但提前把框架搭好）。

选中Move，在右侧面板点击"Add Binding"（加号），选择"Up"（即W键），把指定按键设为W。重复操作分别添加S（Down）、A（Left）、D（Right）。如果要做手柄支持，再加一个"2D Vector"类型的Binding，设为Gamepad左摇杆。

注意这里有个细节：不要用单独的W绑定来做"W键按下时向前移动"，而是把W、A、S、D四个方向键都绑定到同一个Move动作上。Input System会自动把四路方向输入合成一个Vector2值，按W返回(0,1)，按D返回(1,0)，同时按W+D返回(1,1)——这个合成逻辑是内置的，省去了大量方向计算的代码。

3.2 输入层实现：用Action Callback接收玩家意图

在PlayerControls资源上勾选"Generate C# Class"，生成强类型封装类，这样就不用每次通过字符串去匹配Action名字，写起来更安全。

接下来创建输入处理脚本，我命名为PlayerInputHandler.cs。它只负责一件事：把Input System的回调转换成统一的玩家意图数据，通过事件或属性暴露给上层。

csharp复制using UnityEngine;
using UnityEngine.InputSystem;

public class PlayerInputHandler : MonoBehaviour
{
    // 移动输入向量，取值在 -1 到 1 之间
    public Vector2 MoveInput { get; private set; }
    public bool JumpPressed { get; private set; }
    
    private PlayerControls _controls;
    
    private void Awake()
    {
        _controls = new PlayerControls();
    }
    
    private void OnEnable()
    {
        _controls.Enable();
        _controls.Player.Move.performed += OnMovePerformed;
        _controls.Player.Move.canceled += OnMoveCanceled;
        _controls.Player.Jump.performed += OnJumpPerformed;
    }
    
    private void OnDisable()
    {
        _controls.Player.Move.performed -= OnMovePerformed;
        _controls.Player.Move.canceled -= OnMoveCanceled;
        _controls.Player.Jump.performed -= OnJumpPerformed;
        _controls.Disable();
    }
    
    private void OnMovePerformed(InputAction.CallbackContext context)
    {
        MoveInput = context.ReadValue<Vector2>();
    }
    
    private void OnMoveCanceled(InputAction.CallbackContext context)
    {
        MoveInput = Vector2.zero;
    }
    
    private void OnJumpPerformed(InputAction.CallbackContext context)
    {
        JumpPressed = true;
    }
    
    public void ConsumeJump()
    {
        JumpPressed = false;
    }
}

这里有三个细节值得说清楚：

• 为什么用performed和canceled，而不是直接在Update里读MoveInput？因为事件回调的时机是"输入状态发生变化"的时候，比每帧轮询更精准，而且不消费额外CPU。性能差距在这个规模的项目里看不出来，但到了XR场景里上百个交互物体时，事件驱动和轮询的差距就很明显了。
• MoveInput暴露的是一个Vector2而不是两个bool或者单独的上下左右事件，是为了和手柄摇杆的"程度+方向"语义对齐。键盘是0或1，摇杆是-1到1的连续值，用Vector2表达两种设备都能完美适配。
• JumpPressed为什么要用ConsumeJump()来消费而不是直接读？因为跳跃是"一次性事件"，如果漏读了就没了，消费制保证同一帧还是下一帧读取都能拿到值，不会丢失输入。

3.3 表现层实现：物理移动与旋转控制

然后写真正的移动控制脚本BallMovementController.cs。这个脚本挂在小球物体上，负责接收移动方向向量，并操作Rigidbody实现物理运动。

csharp复制using UnityEngine;

[RequireComponent(typeof(Rigidbody))]
public class BallMovementController : MonoBehaviour
{
    [Header("移动参数")]
    [SerializeField] private float moveSpeed = 3.5f;
    [SerializeField] private float turnSmoothTime = 0.05f;
    [SerializeField] private float maxVelocity = 5f;
    
    [Header("跳跃参数")]
    [SerializeField] private float jumpForce = 5f;
    [SerializeField] private LayerMask groundLayer;
    
    private Rigidbody _rb;
    private Transform _cameraTransform;
    private float _turnSmoothVelocity;
    private bool _isGrounded;
    
    private void Awake()
    {
        _rb = GetComponent<Rigidbody>();
        _cameraTransform = Camera.main != null ? Camera.main.transform : null;
    }
    
    public void Move(Vector2 moveInput)
    {
        if (moveInput == Vector2.zero) return;
        
        // 计算移动方向：基于相机朝向做坐标系转换
        Vector3 moveDirection = new Vector3(moveInput.x, 0f, moveInput.y).normalized;
        
        if (_cameraTransform != null)
        {
            // 以相机朝向来重定向移动方向，类似手柄的"朝向相机移动"
            float targetAngle = Mathf.Atan2(moveDirection.x, moveDirection.z) 
                                * Mathf.Rad2Deg 
                                + _cameraTransform.eulerAngles.y;
            moveDirection = Quaternion.Euler(0f, targetAngle, 0f) * Vector3.forward;
        }
        
        // 平滑转向
        float targetRotation = Mathf.Atan2(moveDirection.x, moveDirection.z) 
                               * Mathf.Rad2Deg;
        float smoothAngle = Mathf.SmoothDampAngle(
            transform.eulerAngles.y, 
            targetRotation, 
            ref _turnSmoothVelocity, 
            turnSmoothTime);
        transform.rotation = Quaternion.Euler(0f, smoothAngle, 0f);
        
        // 刚体移动：用velocity直接驱动，不用AddForce
        Vector3 targetVelocity = moveDirection * moveSpeed;
        Vector3 currentVelocity = _rb.velocity;
        targetVelocity.y = currentVelocity.y;  // 保留垂直方向的已有速度
        
        // 平滑过渡，避免突加突变
        _rb.velocity = Vector3.Lerp(currentVelocity, targetVelocity, 10f * Time.deltaTime);
        
        // 速度上限保护
        if (_rb.velocity.magnitude > maxVelocity)
        {
            _rb.velocity = _rb.velocity.normalized * maxVelocity;
        }
    }
    
    public void Jump()
    {
        if (_isGrounded)
        {
            _rb.AddForce(Vector3.up * jumpForce, ForceMode.Impulse);
        }
    }
    
    private void OnCollisionStay(Collision collision)
    {
        // 简单的地面检测
        foreach (ContactPoint contact in collision.contacts)
        {
            if (contact.normal.y > 0.5f)
            {
                _isGrounded = true;
                return;
            }
        }
        _isGrounded = false;
    }
    
    private void OnCollisionExit(Collision collision)
    {
        _isGrounded = false;
    }
}

这段代码里最核心的决策是用_rb.velocity直接赋值而不是AddForce。为什么？AddForce会累加力，导致小球持续加速，速度控制不稳定；velocity赋值则直接设定目标速度，物理引擎在此基础上处理摩擦和碰撞反馈，手感更可控。这在XR移动中很重要——实时交互要求玩家能精准预测物体行为，速度突变的物理模型有利于直觉控制。

你可能注意到我加了个turnSmoothTime和SmoothDampAngle来处理转向。这是为了防止小球面向方向突然跳变，在XR视角里，生硬的旋转会造成明显的晕眩感。平滑转向让运动轨迹更自然，这也是一个为后续VR体验打基础的好习惯。

3.4 逻辑层粘合：把三层串起来

最后需要一个PlayerController.cs来做总调度，把输入层的指令分发给表现层：

csharp复制using UnityEngine;

[RequireComponent(typeof(PlayerInputHandler))]
[RequireComponent(typeof(BallMovementController))]
public class PlayerController : MonoBehaviour
{
    private PlayerInputHandler _inputHandler;
    private BallMovementController _movementController;
    
    private void Awake()
    {
        _inputHandler = GetComponent<PlayerInputHandler>();
        _movementController = GetComponent<BallMovementController>();
    }
    
    private void Update()
    {
        // 处理跳跃（一次性事件）
        if (_inputHandler.JumpPressed)
        {
            _movementController.Jump();
            _inputHandler.ConsumeJump();
        }
    }
    
    private void FixedUpdate()
    {
        // 物理移动在FixedUpdate里做，和物理引擎节奏同步
        Vector2 moveInput = _inputHandler.MoveInput;
        _movementController.Move(moveInput);
    }
}

注意这里Move放在FixedUpdate而不是Update里。物理引擎的步进是固定时间间隔（默认0.02秒），在Update里改刚体属性可能会造成物理帧与渲染帧不同步，导致运动抖动。放在FixedUpdate里能保证与物理引擎同频，运动表现稳定。

这就是为什么三层分离的架构在XR开发中如此重要——你能精准控制每个逻辑发生在什么时机，而不是挤在一起将就。FixedUpdate处理物理，Update处理一次性事件和渲染层逻辑，各司其职。

3.5 场景搭建与参数设置

脚本都准备好后，搭一个测试场景：

地面：创建一个Plane，默认的10×10米尺寸就够用。给Plane添加一个物理材质，摩擦力设为0.4左右，方便小球滚动但不至于失控。Plane的碰撞器默认就有，不需要额外配置。

小球：创建一个Sphere，Scale保持1（半径0.5米）。添加Rigidbody组件，Interpolate设置为Interpolate（渲染更平滑，避免小球飞快的旋转造成视觉抖动）。Collision Detection设为Continuous Dynamic（防止快速运动时穿模穿透地面）。然后挂上PlayerController、PlayerInputHandler、BallMovementController三个脚本。

光源：默认场景自带Directional Light，调整一下角度让阴影投射更清晰，方便观察小球的高度变化。

相机：把主相机调整到可俯瞰小球的位置，比如position(0, 5, -8)，rotation(30度俯视)。相机要挂上AudioListener（默认有），后续接XR设备时这里会替换成玩家视角。

运行后，小球应该能随着WASD按键流畅地前后左右移动。到这里这个项目的基础功能就已经完整可用了。

4. 常见问题排查与避坑实录

这个项目看着简单，但真正跑下来会遇到不少坑。我把自己踩过的、以及帮朋友排查过的几类典型问题整理一下，按出现频率排序。

4.1 按键没反应：Input System没激活或没有生成C#类

现象：运行后按WASD，小球完全不动，控制台也没有报错。

排查步骤：

1. 确认PlayerInputHandler的_controls.Enable()有被调用——检查脚本是否挂在了不相关的空物体上，挂载后是不是被SetActive(false)了。
2. 检查PlayerControls资源上是否勾选了"Generate C# Class"。如果没有勾选，new PlayerControls()这行代码编译都过不了。如果你是从Asset Store下载的示例代码，一定要先在资源面板里勾选这个选项。
3. 在OnMovePerformed回调里加一个Debug.Log(context.ReadValue<Vector2>())，确认回调有没有被触发。如果触发了但小球不动，问题在移动控制器；如果没触发，问题在Input System绑定。

这个排查思路的核心原则是"从输入端往输出端逐层验证"，每次只阻断一个中间节点来定位故障在哪一层。这比盯着代码发呆高效得多。

4.2 小球碰撞穿透地面

现象：小球快速下落或者猛烈撞击时，会直接穿到地板下面。

原因：Unity的PhysX默认使用Discrete碰撞检测，高速物体每帧位移过大时可能跳过碰撞体。小球半径只有0.5米，移动速度在3.5米/秒左右时基本没问题，但如果后续加了跳跃、加了高速冲刺（比如速度超过10米/秒），就很容易触发穿透。

解决方案：把Rigidbody的Collision Detection改为Continuous Dynamic。这个模式会对动态物体做连续碰撞检测，防止穿透。代价是CPU消耗增加，但对XR这种交互精度要求高的场景非常值得。如果你的项目对性能有极致追求，可以只在高速物体上开启这个模式，普通静态环境还是用默认模式。

4.3 移动方向不对：键盘和相机朝向对不上

现象：玩家按"W"（前进），小球往屏幕左前方跑；按"D"（向右），小球往屏幕左下角跑。

原因：Vector3 moveDirection = new Vector3(moveInput.x, 0f, moveInput.y)这句话直接把屏幕坐标映射成了世界坐标。如果相机朝向不是世界坐标的Z轴正方向（默认情况下相机是朝-Z看，但场景里你可能手动旋转了相机），移动方向就会错位。

解决方案：我代码里已经做了相机朝向的坐标系转换——用_cameraTransform.eulerAngles.y把输入向量旋转到相机的世界朝向。这样无论相机怎么转动，按W都是"沿相机观察方向前进"，按D都是"沿相机右方平移"。这是XR、第三人称游戏、第一人称游戏通用的一套标准做法，值得记牢。

4.4 小球的物理手感：太滑溜或太沉重

现象：松手后小球还要滑行好几米才停下，或者转向迟钝、移动发飘。

原因：刚体上的Drag（阻力）和地面的物理材质摩擦力共同决定了小球的运动手感。Drag默认是0，意味着没有运动和旋转阻力，小球确实会一直滑下去。

调节建议：下表是我经过几轮调试得出的经验参数，不同项目会略有差异，但可以参考起始值：

调节时记住一个原则：速度目标值设好后，手感主要由Drag和摩擦力决定，而不是反复改moveSpeed。moveSpeed决定极限速度，Drag和摩擦力决定到达极限速度的快慢和松手后滑行的距离。

4.5 按键延迟明显，按下去小球要过一会儿才动

现象：按键触发看起来有100~200毫秒的延迟，虽然在PC上勉强能玩但体感很差。

原因：多半是物理帧和渲染帧的错拍。如果移动逻辑写在Update里但操作的是刚体，或者FixedUpdate的时间步进被调得过大（比如Project Settings -> Physics里的Fixed Timestep被改成0.05秒甚至更大），就会出现肉眼可感知的延迟。

排查步骤：

1. 确认移动逻辑在FixedUpdate，不在Update。
2. 检查Fixed Timestep是否异常。Unity默认是0.02秒（50Hz），调到0.03秒（33Hz）以上就会有明显延迟感，建议保持在0.02。
3. 如果还是延迟，检查是否在Move方法里对每个按键响应都做了过度的平滑处理——Vector3.Lerp的t参数太小会导致响应变慢。如果10f * Time.deltaTime效果不够灵敏，尝试提高到20f或直接放弃Lerp，用硬赋值_rb.velocity = targetVelocity。

这个细节在XR开发里尤其关键：戴上头显后，感知精度会被放大，一点延迟就足以造成晕眩感。所以XR项目的移动逻辑对实时响应要求极高，宁可放弃一点画面平滑度也要保证操作反馈的即时性。

5. 从键盘到XR设备：交互抽象层的扩展思路

项目做到这里，基础闭环已经完整。但如果仅仅停留在此，那就浪费了这个项目真正值钱的部分——把键盘交互抽象化，让它能平滑迁移到XR设备上。这是我认为这篇文章最值得收藏的段落。

5.1 把键盘输入替换成XR手柄输入

回顾之前的结构：PlayerInputHandler产出MoveInput（Vector2）、JumpPressed（bool），BallMovementController只接收这些抽象数据，完全不知道输入来自什么设备。这就意味着，切换到XR手柄时，只需换掉输入层实现，其余代码一行都不用改。

接入XR手柄，有两个方案：

方案一：用Input System自带的手柄映射。 之前我们在PlayerControls里只绑定了键盘，现在打开Input Actions面板，在Move动作上点击"Add Binding"，选择"Gamepad Left Stick"（游戏手柄左摇杆）。这样同一个Move动作就能同时接收WASD和手柄摇杆的输入，Input System会自动融合——哪个设备有输入就用哪个。XR控制器（比如Oculus Touch）的摇杆通常也会被识别为Gamepad设备，所以这个方案在大部分情况都立竿见影。

方案二：集成XR Interaction Toolkit（XRI）。 如果你是认真做XR项目，推荐直接集成XRI。导入XR Interaction Toolkit包后，创建XR Origin（或者XRI的Component Based Rig），它会自动处理设备追踪。XRI的InputActionManager和XRUIInputModule会接管所有输入事件。这种情况下，你只需要把PlayerInputHandler里的_controls替换成从XRI里读取的InputActionProperty，其他逻辑完全复用。

5.2 转向和移动的XR规范预演

在做键盘控制时有一个细节：turnSmoothTime让小球转向更自然。在XR里，转向逻辑会按照"用户头部朝向"或"手柄指向"来重定向移动方向，而不是世界坐标固定方向。我们代码里已经用_cameraTransform.eulerAngles.y做了相机朝向转换，到了XR场景，这个相机朝向会被头显的追踪位置替代，移动方向的计算逻辑完全一样。

这也是为什么我在代码里提前写了相机转换的部分——很多教程只做世界坐标移动，到XR里一跑就发现方向全乱了。提前用相机朝向做了一次转换，就能很自然地对接XR设备的头部追踪或手柄指向。

5.3 交互扩展：从"移动小球"到"抓住物体"

完成了键盘控制小球后，下一步自然是在场景里加入可交互物体。比如用手柄射线指向小球，扣扳机抓起来，再松开放下。这个功能用XR Interaction Toolkit里的XRGrabInteractable组件就能实现，不用写代码。但关键在于，你通过这个小球项目建立的运动控制、输入抽象、物理反馈的心智模型，能让你在配置这些组件时理解它们在干什么——为什么手柄射线和交互层是分离的、为什么移动逻辑要放在FixedUpdate、为什么物理材质影响抓握手感。这些底层的认知才是这个项目真正留给你的财富。

6. 写在最后的经验沉淀

说实话，这个项目我前前后后做过多遍，每次做都有新的体会。最初是照猫画虎跟着教程敲代码，小球动起来那一刻挺有成就感，但根本不理解为什么要用FixedUpdate和velocity而不是Update和transform.position；后来给一个Unity项目接VR设备，被方向错乱、穿透、延迟问题轮番折磨，才回过头来把这些基础逻辑逐一吃透。

我个人的体会是：XR开发的门槛不在引擎操作，而在对"玩家意图到虚拟物体运动"这条链路的理解深度。键盘控制小球这个看似简单的项目，恰恰是训练这种理解的最小完备样例。它涵盖了输入系统选型、物理运动控制、旋转平滑、分层架构、设备抽象等XR交互开发的所有核心知识点，而且每个知识点都能在普通Unity项目里调试验证。

最后再分享一个小技巧：给移动控制脚本加上[Header("调试信息")]和运行时可视化的当前速度、方向箭头，在Scene视图里挂一个Debug.DrawRay画出小球当前的速度向量。这个比反复手动观察场景直观得多，尤其是调参数找手感的时候，一条箭头线和数值输出能让问题定位快好几倍。我也是踩了好几次坑、反复在"速度对不对"这个问题上挣扎之后，才养成了每次调交互都先可视化调试信息的习惯。希望这篇记录能让你少走几个我走过的弯路。