如果项目已经切到 Unity 新版 Input System 有一阵子了，控件建了，动作也能读到了，但总会遇到一些不上不下的问题：方向键偶尔不灵、自定义改键不会保存、本地多人不知道怎么接、按住蓄力老是断。这篇是系列的第二篇，上一篇聊了怎么从旧 Input Manager 迁移、怎么启用新输入系统、怎么创建第一个 Input Action 资产，这篇就不再重复基础了，直接进入实战。我会把动作资产的完整结构、角色移动的典型配置、代码动态改键、PlayerInput 接入多人、Interaction 与 Processor 的手感调节，以及迁移期最容易翻车的几个坑挨个过一遍。适合已经看完第一篇、准备把输入正式落地到自己项目里的读者，也适合那些被各种诡异输入问题困扰、想一次性把原理理顺的开发者。
如果你现在还停留在“在 Update 里用 Keyboard.current.wKey.isPressed 判断移动”的阶段，那这篇也会帮你把思路理清楚：什么时候该直接用设备状态，什么时候该交给 Input Actions 管。我的建议是，先用一个小 Demo 把下面这套流程完整跑一遍，再决定自己项目里怎么用，不然文档读再多也是纸上谈兵。
1. 先把动作资产的结构彻底搞懂：一个动作是怎么从按键走到游戏逻辑的
1.1 资产、动作映射、动作和绑定到底是什么关系
新版 Input System 的整个设计核心就是 Input Action Asset（输入动作资产），它通常是一个.inputactions文件。很多人第一次打开这个编辑器窗口就懵了，里面又是 Action Maps 又是 Actions 又是 Bindings，层级关系全靠猜。我帮你用一句话理清：Action Map 是一套操作方案，Action 是“想让角色做什么”，Binding 是“具体哪个输入去做这件事”。
打个比方，键鼠操作是一套方案，手柄操作是另一套方案，这就是两个 Action Map。每个方案里都有“移动”“跳跃”“攻击”这些 Action，表示角色意图。而 Binding 就是“移动”这个意图可以来自 W 键、A 键，也可以来自手柄左摇杆，指向哪个设备信号，这就是绑定。一个 Action 可以挂多个 Binding，来源越多，玩家操作的选择就越多。设备上来的裸信号经过 Binding 的映射、处理器的修正，最后变成你能读到的值，这就是一整条链路。
以前旧输入系统里，你用Input.GetAxis("Horizontal")时，背后其实也有一层轴映射，但那是引擎写死的，你很难去动态改。新系统把这层映射彻底开放了，你可以让一个叫“开火”的 Action 绑定到鼠标左键、手柄 RT 键、甚至手机上的一次双指触控。理解了这个三层嵌套结构（方案→动作→绑定），后面所有操作都顺了。
1.2 为什么官方建议勾选 Generate C# Class，而不是每次用字符串查找动作
在 Input Actions 资产编辑器右上角有一个 Generate C# Class 选项，勾选后会自动生成一个强类型类。很多初学者会忽略它，然后在代码里到处写asset.FindActionMap("Gameplay").FindAction("Move")，配合字符串参数。这种写法不是不能用，但有两个问题：一是字符串拼错之后编译期完全不报错，只有运行时才能发现；二是在性能敏感的地方频繁 FindAction 确实有额外开销。
我实测下来，给资产生成 C# 类是最省心的做法。假设资产命名为 GameInput，生成类后你可以直接写var input = new GameInput()，然后input.Gameplay.Move.ReadValue<Vector2>()，全程有代码提示，拼错名会直接编译报错。生成的类里每个 Action Map 就是一个属性，每个 Action 又是一个属性，嵌套结构清清楚楚。
不过要提醒一点：不要因为有了 C# 类就忘了生命周期。你 new 出来的实例里，每个动作默认是不启用的。你必须调用input.Gameplay.Enable()之后，动作才会接收设备的输入。如果你在没 Enable 的情况下直接ReadValue<Vector2>()，Unity 会抛一个InvalidOperationException，提示你“Cannot read value from action ... which is disabled”。这个异常我见得太多了，归根结底就是生命周期管理没做对。
1.3 启用和禁用的最好时机：跟着 MonoBehaviour 的生命周期走
我习惯把 Enable 和 Disable 配对写在脚本的 OnEnable 和 OnDisable 里，而不是 Awake 和 OnDestroy。原因很简单：OnEnable/OnDisable 在对象激活、失活时会反复调用，当你的游戏切场景或者 UI 界面隐藏时，输入动作也能跟着暂停，避免角色在菜单背后还在乱跑。如果你的对象一直存活，那直接写 Awake 里 Enable、OnDestroy 里 Disable 也没有问题，但一旦你后面做弹窗暂停功能，就不得不回来改。
还有一点容易被忽略：如果同一个资产被多个脚本同时引用，每个脚本各自调用 Enable，Unity 内部会做引用计数，不会因为一个脚本 Disable 就把别的脚本也搞停了。但如果你在某个脚本里反复 Enable/Disable 同一个动作，又没配对好，会出现“明明 Enable 了却没反应”的怪现象，这时候先检查是不是 Disable 的次数比 Enable 多。
2. 手把手配置一套完整的角色移动输入：从空白资产到角色能跑能跳
2.1 建资产、建方案、建动作，类型选 Value 还是 Button？
右键 Create > Input Actions，把资产命名为 GameInput。双击打开编辑器，先新建一个 Action Map，我习惯叫 Gameplay。然后在里面创建四个 Action：Move、Look、Jump、Attack。创建的时候注意 Action Type 选择。
Move 和 Look 必须选 Value，并且 Control Type 选 Vector2，因为它们是持续变化的二维方向量。Jump 和 Attack 选 Button 就够了，它们本质上是数字信号，按下触发、松开结束。这个选择直接影响你后面读取值的方式：Value 用ReadValue<Vector2>()，Button 用事件回调更舒服。
有一点要特别说明：Action Type 里的 Value 和 Button 不是搞着玩的，它们决定了动作在“值改变时怎么通知你”。如果你把 Jump 设成 Value，那么它的值会在 0 和 1 之间变化，你用performed回调也能收到，但代码语义会很奇怪；反过来你把 Move 设成 Button，那手柄摇杆的模拟量就丢了，只剩按下和没按下。所以动手之前一定想清楚每个动作的输入性质。
2.2 给移动加组合绑定：WASD 和手柄左摇杆怎么合并成一个二维向量
选中 Move 动作，点 Add Binding，你会发现有 Composite（组合）选项。选择 2D Vector，它会生成一个组合绑定，下面带四个子绑定：Up、Down、Left、Right。这四个子绑定分别绑定到键盘的 W、S、A、D 键。编辑器里双击每个子绑定右侧的 Bind 按钮，直接按一下键盘就能自动录上路径，这一步非常方便。
但这里有个新手很容易犯的错：只配了键盘组合，忘了手柄。然后玩家插上手柄一推摇杆，角色纹丝不动。正确做法是再加一条绑定，路径直接选择<Gamepad>/leftStick。注意，手柄这条不需要再选 2D Vector Composite，因为它本身就是一个 Vector2 信号，直接作为 Move 的绑定就行。
你可能想问：如果键盘和摇杆同时有输入，这个值会怎么算？新系统的默认行为是“取最后产生输入的设备”，如果你同时按键盘和摇杆，可能产生冲突。解决方法是给两组绑定分 Control Scheme：键盘鼠标一张方案、手柄一张方案，设备接入时系统自动选方案。这个在多人游戏里很关键，单人模式就无所谓了。
2.3 绑定上直接挂处理器：没有死区的摇杆会把你逼疯
设备裸信号往往不能直接用。手柄摇杆因为硬件磨损或公差，在你不碰它的时候，输出值不一定是 0，可能是 0.03、0.05。如果你直接把这个值拿去做移动，角色就会出现轻微的漂移，玩家会以为是手柄坏了，其实是没用死区处理器。
在 Move 的键盘组合子绑定和手柄绑定上，右侧 Properties 里都能添加 Processors。推荐加一个 Stick Deadzone（摇杆死区），把 Min 设为 0.125f。这个数值不是拍脑袋定的，主流手柄的物理死区大致在这个范围附近。加了死区之后，摇杆输出低于这个阈值的部分会被压到 0，超过阈值后会重新映射到 0 到 1 的范围，手感干净很多。
同理，Look 动作你可以考虑加 Sensitivity 处理器，用来统一键鼠和手柄的视角灵敏度。但注意，处理器的执行顺序是从上到下的，如果你加了多个处理器，顺序不同结果完全不同。比如先 Scale 再 Deadzone，和先 Deadzone 再 Scale，对微小漂移的过滤效果完全不一样。这个坑我在第 5 节单独拿出来讲，因为它太容易被忽略。
2.4 生成 C# 类并跑起来：一个最小可用的角色移动脚本
在资产编辑器右上角勾选 Generate C# Class，Unity 会在同目录生成一个 GameInput.cs 文件。然后写一个最简单的角色移动脚本，假设资产名是 GameInput：
using UnityEngine; using UnityEngine.InputSystem; public class SimplePlayerMotor : MonoBehaviour { [SerializeField] private float moveSpeed = 5f; private GameInput input; private void Awake() { input = new GameInput(); } private void OnEnable() { input.Gameplay.Enable(); } private void OnDisable() { input.Gameplay.Disable(); } private void Update() { Vector2 move = input.Gameplay.Move.ReadValue<Vector2>(); Vector3 dir = new Vector3(move.x, 0f, move.y); transform.position += dir * (moveSpeed * Time.deltaTime); } }把脚本挂到一个 Capsule 物体上，按下 Play，用 WASD 就能推动角色。如果手柄插着，左摇杆也能动。这里 Move 读取的是一个 Vector2，x 对应左右，y 对应前后，我转成三维坐标时直接用了 x 和 z，这是最普通的第三人称平面移动写法。如果你做的是俯视角，可能需要不同的轴映射，但思路完全一样。
3. 代码才是完全体：运行时读取、启停、改键、保存自定义配置
3.1 三种读取输入的方式，别一种用到死
新输入系统提供了三种读输入的手段：主动读值、事件回调、直接查询设备状态。很多人上来只学一种，然后抱怨不够用。实际上它们各有各的适用场景，我用一张表总结：
| 读取方式 | 适合场景 | 备注 |
|---|---|---|
action.ReadValue<T>() | 持续状态，比如移动、摇杆 | 配合 Actions 使用，需要先 Enable |
action.performed/canceled事件 | 瞬时行为，比如跳跃、攻击、确认 | 能区分按下和松开，手感控制更细 |
Keyboard.current.wKey.isPressed | 快速原型、单机关卡调试 | 绕开 Actions，适合三五行的临时逻辑 |
我最常用的搭配是：移动类持续量用 ReadValue，在 Update 里每帧读取；跳跃、攻击这类瞬时动作用事件回调，在 performed 里触发一次逻辑。为什么不建议跳跃也用 ReadValue 每帧轮询？因为你要自己判断从 0 变 1 的那一段上升沿，代码写起来容易出边界问题。比如跳跃需求是“按下瞬间起跳”，如果你每帧读值判断previous == 0 && current == 1，逻辑上没问题，但按键重复触发、输入间隔等问题都要你自己处理，事件回调把这些都封装好了。
3.2 用 PerformInteractiveRebinding 做自定义按键
自定义按键几乎是所有游戏都逃不掉的需求。用新系统的PerformInteractiveRebinding实现起来比想象中简单，但有几个细节不注意会卡很久。
首先明确要改的是哪个动作的哪个绑定索引。例如 GameInput 资产里 Jump 动作有两条绑定：一条键盘空格，一条手柄 A 键。如果玩家想改键盘那条，就要拿到键盘绑定对应的 bindingIndex。你可以通过SomeAction.bindings遍历，找到 path 里带Keyboard的那一条。
真正启动重新绑定的代码如下：
using UnityEngine.InputSystem; private InputActionRebindingExtensions.RebindingOperation rebindOperation; public void StartRebind(InputAction action, int bindingIndex) { action.Disable(); rebindOperation = action.PerformInteractiveRebinding(bindingIndex) .WithControlsExcluding("<Mouse>/position") .WithControlsExcluding("<Mouse>/delta") .OnMatchWaitForAnother(0.1f) .OnComplete(operation => FinishRebind(action, operation)) .OnCancel(operation => FinishRebind(action, operation)) .Start(); } private void FinishRebind(InputAction action, InputActionRebindingExtensions.RebindingOperation operation) { action.Enable(); operation.Dispose(); // 根据 action.bindings[bindingIndex].effectivePath 刷新UI显示 }这段代码里有三个提醒。第一，重新绑定前要把 action 先 Disable，否则设备事件还在正常处理，新的绑定信息可能被旧状态干扰；第二，WithControlsExcluding用来排除鼠标位置和鼠标移动这两类设备，否则玩家按一下鼠标左键，系统会把绑定当成“鼠标位置”而不是“左键”，这属于 GetBindingIndex 阶段最常踩的坑；第三，OnMatchWaitForAnother(0.1f)是为了避免检测到两个同时按下的键时直接结束，比如玩家按了一个键又快速碰到别的东西，0.1 秒的缓冲能让结果更准确。
另外，Operation 是一个一次性对象，完成或取消之后务必调用Dispose()，否则会泄漏监听。我见过同事忘记 Dispose，导致每次改键后游戏的内存悄悄上涨，还找不出原因。
3.3 把自定义绑定保存进存档，下次启动还能用
改完键不保存等于白改。新系统提供两种持久化方案：针对单个动作或整个资产的绑定覆盖序列化。我推荐使用SaveBindingOverridesAsJson()和LoadBindingOverridesFromJson()，因为这两个方法只保存被修改过的绑定，不会把整个资产文件覆盖掉，下次加载也很轻量。
using UnityEngine; using UnityEngine.InputSystem; public static class BindingSaveUtil { private const string SaveKey = "CustomBindings"; public static void Save(InputActionAsset asset) { var overrides = asset.SaveBindingOverridesAsJson(); PlayerPrefs.SetString(SaveKey, overrides); PlayerPrefs.Save(); } public static void Load(InputActionAsset asset) { if (PlayerPrefs.HasKey(SaveKey)) { asset.RemoveAllBindingOverrides(); asset.LoadBindingOverridesFromJson(PlayerPrefs.GetString(SaveKey)); } } }注意加载之前先调用RemoveAllBindingOverrides()，因为覆盖是和默认绑定叠加的，不清空直接加载，上次的覆盖会残留。实际操作中，我通常在游戏主界面加载完存档后立刻调用一次 Load，然后走一遍所有 Action 的绑定列表，把 UI 上的按键提示全部刷新。这样玩家一进游戏就看到的是自己设置的键位，而不是默认键位。
4. PlayerInput 与本地多人：一个动作资产服务四个手柄
4.1 PlayerInput 组件的正确打开方式
如果你只需要单机单人，前面那些已经够用了。但一旦要支持本地多人，比如双人同屏或者四手柄玩聚会游戏，直接用 PlayerInput 组件会更省事。你把 PlayerInput 组件挂在玩家预制体上，指定 Actions 为 GameInput，Default Map 选 Gameplay，然后它就会自动监听设备输入，并把对应 Action Map 的事件转发给预制体上的脚本。
组件上有一个 Notification Behavior 下拉框，三种模式分别是 Send Messages、Invoke C# Events、Invoke Unity Events。我强烈建议用 Invoke Unity Events，因为它在 Inspector 里直接把事件函数拖出来绑定，可视化程度最高，团队合作时别人一眼就能看出这个组件会调用哪些方法。Send Messages 虽然也能工作，但靠字符串方法名匹配，改名的时候容易悄悄失联。
4.2 用 PlayerInputManager 处理玩家加入和离开
要实现“按任意键加入”这种常见本地多人逻辑，需要给场景挂一个 PlayerInputManager 组件。它有一个 Joining Behavior 选项，我一般选 Join Players via Button，这样每个尚未被占用的设备在按下指定键后就会生成一个预制体玩家。
在代码里监听玩家的加入和离开事件，注意事件要挂在 PlayerInputManager 实例上：
using UnityEngine; using UnityEngine.InputSystem; public class LocalMultiplayerSpawner : MonoBehaviour { public GameObject playerPrefab; public Transform[] spawnPoints; private void OnEnable() { PlayerInputManager.instance.onPlayerJoined += OnPlayerJoined; PlayerInputManager.instance.onPlayerLeft += OnPlayerLeft; } private void OnDisable() { if (PlayerInputManager.instance) { PlayerInputManager.instance.onPlayerJoined -= OnPlayerJoined; PlayerInputManager.instance.onPlayerLeft -= OnPlayerLeft; } } private void OnPlayerJoined(PlayerInput playerInput) { playerInput.transform.position = spawnPoints[playerInput.playerIndex % spawnPoints.Length].position; Debug.Log($"玩家 {playerInput.playerIndex + 1} 已加入，设备：{playerInput.devices[0]}"); } private void OnPlayerLeft(PlayerInput playerInput) { Debug.Log($"玩家 {playerInput.playerIndex + 1} 已离开"); } }有一个细节要提前设计好：PlayerInput 的playerIndex是加入顺序的全局索引，不是固定玩家的编号。中途有玩家离开再加入，新玩家的 playerIndex 可能会变，如果你用它来分配角色颜色或者出生点，要特别小心。我更建议自己维护一个使用中的索引列表，玩家加入时从列表里取一个空闲 ID，离开时释放，这样才不会出现两个人抢同一个颜色。
4.3 分屏区域、相机绑定和 UI 事件分发
本地多人最容易出现的问题就是玩家 1 按手柄 A 键，结果把玩家 2 的 UI 菜单也确认了。旧输入系统做这种设备过滤极其痛苦，PlayerInput 组件自带解决方案。每个 PlayerInput 上有一个camera属性，你把对应的分屏相机拖进去，它就会自动把输入事件和渲染区域关联起来。在做分屏时，给每个玩家预制体挂一个 Camera，并把 Camera 的 Viewport Rect 设置成对应的屏幕区域，比如四分之屏的坐标位置。
UI 部分用的是 InputSystemUIInputModule，同样可以直接从 PlayerInput 上拖引用。每个 PlayerInput 会拥有它绑定的那套设备事件，UI 操作各响应各的，互不干扰。实测下来，两双手柄同时操作两个不同菜单时，不会串键，这个体验比旧版好了不是一个量级。如果项目里有“大厅按 A 加入、菜单各自选择角色”这种流程，用 PlayerInput 加 InputSystemUIInputModule 几乎可以无缝实现。
4.4 Control Scheme 切换：同一个动作在键鼠和手柄下表现出不同状态
Control Scheme 听起来很高端，其实就是一个带名字的绑定分组。在资产编辑器底部可以配置 Control Scheme，然后你在每个 Binding 上勾选它属于哪个方案。PlayerInput 会根据当前玩家使用的设备，自动选择匹配的 Control Scheme。
举个例子，移动动作我想让键鼠玩家按 WASD，手柄玩家推摇杆。你给移动动作添加两种绑定组合，分别挂到“Keyboard”和“Gamepad”这两个方案里。玩家用手柄加入时，PlayerInput 只启用 Gamepad 方案里的绑定；键鼠玩家加入时启用 Keyboard 方案。这样就不用担心有人键盘手柄混着插导致输入冲突了。
还有一个常见坑：如果你的 PlayerInputManager 允许任意设备加入，那么电脑上的鼠标键盘也会被当成一名“玩家设备”。如果你不想让键盘鼠标成为玩家设备，需要在 Control Scheme 中设置 Required Device，或者在 PlayerInput 的事件回调里判断playerInput.devices是否包含Keyboard.current，是的话直接踢掉。这些细节我在项目里反复调整过，最后发现还是在 Control Scheme 上手动指定设备最直观。
5. 让手感顺滑：Interaction 和 Processor 到底怎么排才不会打架
5.1 Interaction 决定“什么时候算按下”，别小看这个时机问题
Interaction 是“交互模式”，它规定了动作从空闲到触发、再到取消的完整节奏。默认情况下，Button 类型的动作使用 Press 交互，也就是按下瞬间触发performed，松开是canceled。但真实游戏的输入千变万化，你想做短按、长按、双击，都要靠 Interaction 来实现。
我列一下实战中最常用的几种：
| 交互类型 | 典型应用场景 | 关键参数 |
|---|---|---|
| Press | 开火、跳跃、确认 | Trigger Behavior：PressOnly / ReleaseOnly / PressAndRelease |
| Hold | 蓄力攻击、长按装扮 | Min Hold Duration，通常 0.3~1.0 秒 |
| Tap | 快速点击、轻攻击 | Max Tap Duration，默认 0.2 秒 |
| SlowTap | 慢速点击、轻/重区分 | Min Tap Duration，需要自己调 |
| MultiTap | 双击动作、三连击彩蛋 | Tap Count、Tap Delay |
这里必须提醒一个反直觉的行为：给同一个 Action 挂多个 Interaction 时，Unity 会按添加顺序依次竞争，一旦其中一个判定完成，其他交互就会被取消。所以很多人想“又支持点击开火，又支持按住蓄力”，把 Tap 和 Hold 同时挂在一个动作上，结果短按时偶尔会触发蓄力，长按时又因为 Tap 抢先判定导致蓄力中断。正确做法是用两个 Action，一个叫 LightAttack 挂 Tap，一个叫 ChargeAttack 挂 Hold，然后根据游戏逻辑决定当前应不应该读取哪个动作。
5.2 Processor 的执行顺序：先处理死区，再做任何修饰
Processor 是“处理器”，在绑定信号的输出和动作值之间做数据修正。你在绑定右侧的 Processors 列表里看到的顺序，就是从设备原始值到动作最终值的计算顺序。这个顺序看着不起眼，实际上差别非常大。
举个例子：手柄摇杆原始输出 0.1，如果处理器顺序是 Scale 2 在前、Deadzone 在后，那么 0.1 先被放大成 0.2，再进死区（假设死区阈值 0.125），0.2 大于阈值，反而能透过死区触发移动。这明显是我们不想要的：摇杆轻微漂移 0.1，放大后就能推动角色了。但如果你把 Deadzone 放在最前面，0.1 直接小于阈值被抹成 0，后面的 Scale 再怎么放大都还是 0。
所以我的经验是：**任何对原始值做范围修正、归一化、映射的处理器，都应该排在 Deadzone 之后。**具体到移动动作上，我给摇杆绑定的处理器顺序一般是 Stick Deadzone -> Normalize Vector2（可选） -> Scale Vector2（按手感缩放）。Look 动作可以额外加 Invert Vector2，但注意如果你先 Invert 再 Scale，翻转后的负数再跟灵敏度相乘，结果的符号可能被 Scale 里的负值再次翻转，逻辑会乱。遇到这种问题，别急着调参数，先看列表里处理器顺序是不是合理。
5.3 一个真实案例：按住蓄力为什么总是断
我负责的某动作游戏里，有一个“按住攻击键蓄力，松开后释放”的玩法。最开始设计时，直接把 Attack 动作设为 Button 类型，然后在上面挂了一个 Hold Interaction，Min Hold Duration 设为 0.5 秒。结果测试反馈：短按偶尔触发蓄力，长按有时还没到 0.5 秒就取消了。
排查了很久，最后打开 Window > Analysis > Input Debugger，盯着事件流看才发现问题。因为动作默认还有一个 Press 交互的隐式判定，和 Hold 交互同时存在时，Press 在按下瞬间优先完成，把 Hold 的后续流程全部截断了。也就是说，游戏里“按住 0.5 秒”的判定根本没机会完成。后来我把 Press 的 Trigger Behavior 改成 ReleaseOnly，并且把 Attack 动作上的其他 Interaction 全部去掉，只留 Hold，问题才解决。
这个案例告诉我们两件事：第一，Interaction 加到 Action 上之后，不是“加得越多功能越多”，而是会发生竞争关系；第二，调试输入问题不要只盯着代码打日志，Input Debugger 里的事件轨迹能直接告诉你 Action 到底经历了哪些相位变化。找不到问题时就去看它，比猜快得多。
6. 从旧版迁移过来，最容易翻车的三个地方
6.1 Active Input Handling = Both 的陷阱
很多教程为了让新旧输入系统兼容，建议 Player Settings 里的 Active Input Handling 设置为 Both。我一开始也觉得这样稳妥，实际项目里才发现这是个温柔陷阱。
Both 模式意味着场景里只要存在旧代码，比如Input.GetTouch、Input.GetAxis，它和新系统的输入会同时生效。如果同一段逻辑里新旧都用，就会造成双份触发，最常见的就是 UI 点击一次，按钮响应两次；移动端触摸一次，触控事件处理两遍。我曾在某个版本里因为没注意到一个旧插件还在用Input.mousePosition，导致点击交互全部重复，排查了一个晚上才意识到是 Both 模式的问题。
推荐做法是：项目决策切到新输入系统之后，尽早把 Active Input Handling 改成 Input System Package (New)。切换之前先全局搜一下代码里有没有UnityEngine.Input的旧 API，有就改完再切。要是暂时无法清理干净，至少要建立规范，明确新旧 API 不能混用。
6.2 UI 点击失效：EventSystem 上的模块必须换新
切到新输入系统后，场景里的 EventSystem 不会自动升级。如果你用旧版 Unity UI 的默认组件，EventSystem 上挂的还是StandaloneInputModule，它在新的输入系统下不会收到任何输入事件，表现就是鼠标悬停有效果，但点击按钮一点反应也没有，滚轮滚动更是完全失效。
解决办法很直接：把 EventSystem 上的 StandaloneInputModule 删掉，挂上InputSystemUIInputModule。新版组件在 Inspector 里有很多可调项，但默认配置已经能覆盖绝大多数 UI 场景了。如果你在做移动端，记得在组件上把 Pointer Behavior 设置为 Compatible 模式还是 Preferred 模式，这个会影响到多点触控的响应细节，最好根据真机实测选择。
还有个容易被忽略的坑：如果场景里的主摄像机没有挂 Physics Raycaster，那么 EventSystem 的射线检测不会命中 3D 物体，比如点击 3D 场景里的敌人没有反应。这种情况在旧版也存在，但新版输入系统下导致的困惑更多，因为点击失效你第一反应是怀疑输入系统，其实只是缺了一个射线组件。
6.3 移动端触控坐标与 Canvas 坐标不一致
移动端真正开发时，想自己处理触控点，会发现手机上的触点坐标和 Canvas 坐标直接对不上。新系统里Touchscreen.current.primaryTouch.position返回的是屏幕像素坐标，和旧版的Input.GetTouch(0).position一样，坐标原点在屏幕左下角，横屏竖屏都如此。而 Canvas 内部的坐标是 UGUI 的逻辑坐标，受 Canvas Scaler 的缩放模式影响。
如果你只是判断“玩家碰到了屏幕上方区域”，那直接用像素坐标除以屏幕宽高比就行。但如果要把触控点映射到某个 UI 元素上，更好的办法是不要手动算，交给 InputSystemUIInputModule，或者用RectTransformUtility.ScreenPointToLocalPointInRectangle方法转换坐标。我踩过的坑是：Canvas 的 Render Mode 选择了 Screen Space - Camera，然后我按世界坐标算触控点，结果像素坐标和 UI 坐标差距巨大，最后用 ScreenPointToLocalPointInRectangle 一行就解决了。
6.4 调试输入问题的标准姿势：先看 Input Debugger，再写代码
遇到“这个按键为什么没响应”这类问题，我的排查顺序永远是：打开 Input Debugger 看设备有没有上报事件，再看 Action 的事件轨迹，最后才怀疑自己的代码逻辑。顺序反过来的话，你很容易被自己的臆测带偏。
Input Debugger 在 Window > Analysis > Input Debugger 菜单下找到，打开后能看到所有设备的状态，包括键盘、鼠标、手柄、触控。如果你按下一个键，设备列表里对应的键位应该有事件记录；如果记录都没有，说明信号根本没进输入系统，不是代码的问题，而是设备和绑定路径的问题。如果设备有事件但 Action 没触发，那就是绑定路径配错了，或者该 Action 没有被启用。这套排查流程我用了很久，基本上能解决九成输入问题。
写在新版输入系统落地之后的一点体会
回头看我个人项目的经验，最想分享的一点是：不要在项目刚开始时迷信“一定要用 Input Actions 资产”。如果你只是做个两天就能玩的小原型，直接Keyboard.current.wKey.isPressed加一个 InputSystemUIInputModule，完全够用。但只要你确定项目要跨平台、要开放改键、要做本地多人，那就尽早切到 Assets + PlayerInput 的方案。前期概念理解确实有成本，但等你在移动端、PC、手柄之间来回切换不再需要改代码时，你会庆幸当初花的那几天学习时间。
按键存档那个功能，我建议做成一个独立工具类，像我在第 3.3 节给的那种封装，项目启动时加载一次，所有输入提示 UI 都从绑定列表里动态生成。如果你还能把“恢复默认键位”这个功能加上，基本上玩家体验就完整了。新版输入系统最复杂的那层概念，撑过了前两周之后，日常开发其实是相当顺手的。希望这些实战细节能帮你少踩几个我踩过的坑。
