开场凌晨三点，QA 群里又炸了：玩家反馈 iPad 上的双指缩放偶尔没反应，安卓模拟器上明明按了 R 键却释放不了技能，手柄热拔插之后角色自己往左跑。你翻看代码发现：Input.GetKey散落在 200 多个脚本里，按键映射写死在字符串字面量中，触摸事件被某个 UI 面板吞掉——既没冒泡到场景，也没触发角色。这种输入系统撑得起原型，但撑不起一款要上架多平台的中型游戏。下面这套方案，是踩过无数坑后沉淀下来的复杂输入系统架构。它不是"封装一个 InputManager 单例"那么简单，而是把设备抽象、动作映射、手势识别、事件分发四件事彻底解耦。文章会讲清每一层"做什么"，更重要的是"为什么非分层不可"。一、为什么必须分层：直接读 Input 的四宗罪在讲架构前先把动机立住。直接在业务代码里Input.GetKey(KeyCode.Space)有四个结构性缺陷：不可配置：改键位要全文搜索字符串，玩家自定义按键更是无从谈起；不可测试：单元测试没法"按下一个键"，自动化回放更是不可能；不可回放：网络同步、死亡回放、TAS 工具都需要"输入序列可记录、可重放"，轮询式读取天然丢失时序；平台耦合：触屏没有 KeyCode，手柄有模拟量，键鼠有组合键——业务代码直接面对平台 SDK，等于把平台差异传染给每一个玩法脚本。由此导出四层架构，自下而上：