1. 为什么一个INI文件值得花三天逐行啃透UE5项目跑起来后手柄按键没反应、键盘快捷键突然失效、PC端和主机端输入行为不一致——这类问题在中大型项目里几乎每周都会冒出来。我上个月帮一个30人团队排查一个“Shift鼠标左键拖拽视角卡顿”的问题最终定位到不是蓝图逻辑或Tick频率而是BaseInput.ini里一行被注释掉的AxisConfig配置在特定DPI缩放下触发了双重采样。这让我意识到绝大多数UE5输入问题的根因不在C代码里也不在蓝图里而就藏在那个看起来人畜无害、连IDE都不高亮语法的BaseInput.ini文件中。这个文件不是运行时生成的缓存也不是可选的配置项它是UE5输入系统启动时最先加载的原始输入契约。它定义了“引擎认为这个世界有哪些输入源”“每个输入源的原始信号如何映射为游戏语义”“不同平台间如何保持行为一致性”三大底层契约。关键词是BaseInput.ini、UE5输入系统、InputConfig、AxisConfig、ActionMapping、AxisMapping、PlatformMappings——这些不是文档里的术语堆砌而是你每天调试时真正在和它们打交道的对象。如果你还在靠“改完保存→重启编辑器→试两下→再改”这种循环来调输入或者把输入问题一股脑扔给TA说“手柄不识别”那这篇就是为你写的。它不讲虚的架构图只带你一行行读透BaseInput.ini的每一类Section、每个Key的物理意义、每处注释背后的工程权衡以及——最关键的是当它出问题时你该盯着哪几行看、怎么改才不会引发连锁异常。接下来的内容全部来自我在6个UE5商业项目含2个主机平台移植中反复修改、回滚、抓包验证的真实经验。2. BaseInput.ini的物理结构与加载时序它到底在输入链路中站什么位置2.1 文件位置与加载优先级为什么改了没生效BaseInput.ini的默认路径是Engine/Config/BaseInput.ini但它绝不是唯一生效的输入配置文件。UE5采用多层覆盖式配置加载机制其加载顺序严格遵循以下优先级从低到高Engine/Config/BaseInput.ini引擎基线配置Game/Config/DefaultInput.ini游戏项目默认配置Game/Config/[Platform]/[Platform]Input.ini如Windows/Input.ini、Console/Input.ini运行时通过UInputSettings::LoadConfig()动态加载的自定义INI编辑器内UI手动修改并保存的Game/Config/EditorInput.ini提示很多开发者改了BaseInput.ini却没效果根本原因是项目已存在DefaultInput.ini且其中定义了同名ActionMapping。UE5会用高优先级配置完全覆盖低优先级配置而非合并。验证方法在编辑器中打开Edit → Editor Preferences → Input点击右下角“Reset to Default”此时编辑器会强制重新加载所有层级配置并显示当前生效的完整映射列表。BaseInput.ini之所以关键在于它定义了所有后续配置的合法输入源集合。比如你在BaseInput.ini中未声明Gamepad_LeftX这个Axis那么即使DefaultInput.ini里写了AxisConfig(AxisNameGamepad_LeftX,Scale1.0)引擎在初始化时也会直接忽略该配置并在日志中输出LogInput: Warning: Axis Gamepad_LeftX not found in input config——但这个警告极容易被海量启动日志淹没。2.2 文件Section的四大核心区块及其不可替代性BaseInput.ini按功能划分为四个逻辑Section每个Section解决一类根本性问题Section名称核心职责典型内容示例修改风险等级[ConsoleVariables]控制输入子系统的全局开关p.IE.AllowMouseCapture1p.IE.AllowGamepadCapture1⚠️⚠️⚠️ 高影响整个输入管线[ActionMappings]定义“玩家意图”的抽象动作ActionMappings(ActionNameJump,KeySpace,bShiftFalse,bCtrlFalse,bAltFalse,bCmdFalse)⚠️ 中影响蓝图和C事件绑定[AxisMappings]定义连续输入的数值映射AxisMappings(AxisNameMoveForward,KeyW,Scale1.0)AxisMappings(AxisNameTurn,KeyMouseX,Scale1.0)⚠️⚠️ 高Scale错误导致移动速度翻倍/归零[PlatformMappings]声明跨平台输入源的物理对应关系PlatformMappings(PlatformWindows,KeyGamepad_LeftX,SourceGamepad Left Thumbstick X)⚠️⚠️⚠️ 极高主机移植失败主因这里必须强调一个反直觉事实[ActionMappings]和[AxisMappings]中的Key值并非操作系统原生键码而是UE5内部定义的“虚拟键名”。例如KeyGamepad_LeftX在Windows平台实际对应XInput的XINPUT_GAMEPAD_LEFT_THUMB_X在Switch平台则对应HID的HID_USAGE_GENERIC_X。这个映射关系由[PlatformMappings]Section精确控制。如果某平台缺失对应条目该Axis在该平台将永远返回0。2.3 加载时序的魔鬼细节为什么有些配置在PIE中不生效UE5编辑器在Play In EditorPIE模式下会创建一个独立的GameInstance实例其输入配置加载流程与打包后游戏存在关键差异打包游戏启动时依次加载BaseInput.ini→DefaultInput.ini→Windows/Input.ini以Windows为例全部加载完成后才初始化UInputComponent。PIE模式编辑器会先加载BaseInput.ini和DefaultInput.ini但在启动PIE前会强制注入一套调试专用映射位于Editor/Config/EditorInput.ini覆盖所有bShift/bCtrl等修饰键配置目的是防止编辑器快捷键与游戏内快捷键冲突。这就解释了为什么你可能遇到“打包后ShiftQ正常退出但PIE里按ShiftQ却触发了编辑器的“Quick Save””。解决方案不是改BaseInput.ini而是检查Editor/Config/EditorInput.ini中是否对Q键做了全局拦截。这个细节在官方文档中几乎从未提及却是团队新人踩坑率最高的点之一。3. ActionMappings深度解析从空格键到“跳跃”动作的完整语义链3.1 单行配置的字段解剖每个参数都是精心设计的工程取舍以BaseInput.ini中最常见的ActionMapping为例ActionMappings(ActionNameJump,KeySpace,bShiftFalse,bCtrlFalse,bAltFalse,bCmdFalse)表面看只是绑定空格键但每个字段都承载着明确的工程意图ActionNameJump这是C中UInputComponent::BindAction(Jump, ...)和蓝图中“InputAction Jump”节点的唯一标识符。它必须全项目唯一且大小写敏感。曾有项目因复制粘贴时多了一个空格变成Jump 导致蓝图节点始终收不到事件排查耗时两天。KeySpace此处Space是UE5预定义的FKey枚举值对应EKeys::Space。它不是字符串匹配而是编译时硬编码的整数ID。这意味着你不能写KeySpace带引号也不能写KeySPACE大小写错误否则引擎在解析INI时会静默忽略该行并在日志中输出LogConfig: Warning: Invalid key name SPACE in ActionMappings。bShiftFalse等修饰键这些布尔值决定了触发该Action所需的完整按键组合。关键点在于修饰键状态是在按键按下瞬间捕获的而非释放时。因此bShiftTrue表示“按住Shift的同时按下空格”而不是“先按Shift再按空格”。这对实现“Shift空格二段跳”类功能至关重要——如果误设为bShiftFalse玩家松开Shift后再按空格仍会触发跳跃逻辑完全错乱。注意UE5 5.3起新增bRequireModifier参数默认False当设为True时该Action仅在修饰键被按下时才响应松开修饰键后即使主键还按着也不会触发。这是实现“按住Shift才开启瞄准镜”类功能的正确姿势而非依赖蓝图中每帧检测Shift状态。3.2 多键绑定的底层机制为什么一个Action能绑多个KeyBaseInput.ini支持同一ActionName绑定多个Key例如ActionMappings(ActionNameFire,KeyLeftMouseButton) ActionMappings(ActionNameFire,KeyRightMouseButton) ActionMappings(ActionNameFire,KeyMouseScrollUp)这看似方便但背后是UE5输入系统的一个关键设计每个ActionMapping条目在内存中生成一个独立的FInputActionKeyMapping对象它们共享ActionName但互不影响。这意味着当玩家同时按下左键和右键时Fire事件会被触发两次除非你在C中显式去重MouseScrollUp的触发逻辑与鼠标键完全不同——它基于滚轮delta值每次滚动触发一次而非按下/释放如果你在蓝图中使用“InputAction Fire”节点它会自动聚合所有绑定Key的触发事件无需额外处理。这个设计的工程价值在于它让UI交互如鼠标点击和游戏玩法如射击能复用同一套Action语义而无需为不同输入设备编写不同逻辑。但代价是如果你在DefaultInput.ini中又加了一行ActionMappings(ActionNameFire,KeyGamepad_RightTrigger)那么主机玩家按扳机时事件触发频率会远高于PC玩家按鼠标——因为扳机是模拟量引擎会根据压力值持续触发而鼠标是数字开关。解决方案是在C中检查const FInputActionValue Value的GetValue().Getfloat()是否大于阈值而非直接响应。3.3 ActionMapping的生命周期陷阱为什么热重载后绑定丢失在开发过程中我们常通过UInputSettings::UpdateInputSettingsFromConfig()动态重载输入配置。但一个致命陷阱是已绑定的UInputComponent不会自动更新其Action映射。假设你在C中这样绑定InputComponent-BindAction(Jump, IE_Pressed, this, AMyCharacter::OnJumpPressed);然后在运行时修改BaseInput.ini并调用UpdateInputSettingsFromConfig()OnJumpPressed函数依然只会响应旧的Key绑定新配置完全无效。根本原因在于BindAction在调用时会将ActionName与当前输入系统中注册的Key映射快照Snapshot关联。重载INI只是更新了引擎的全局映射表但已存在的Binding对象仍指向旧快照。正确做法是在重载配置前先调用InputComponent-RemoveActionBinding(Jump, IE_Pressed)再调用UInputSettings::UpdateInputSettingsFromConfig()最后重新BindAction。这个流程必须成对出现漏掉任何一步都会导致输入行为诡异。我在一个AR项目中曾因此出现“手机陀螺仪校准后虚拟摇杆失灵”的问题根源就是重载配置时忘了清理旧Binding。4. AxisMappings技术深潜从鼠标X轴到“转向”数值的精密标定4.1 Scale参数的物理意义它不是简单的乘法因子AxisMapping最易被误解的字段是ScaleAxisMappings(AxisNameTurn,KeyMouseX,Scale1.0)新手常认为Scale2.0就是“转得更快”但真相是Scale是将原始输入设备的物理位移Pixels或Raw Device Units转换为UE5标准化的[-1.0, 1.0]区间的关键系数。其计算公式为NormalizedValue RawValue * Scale * Sensitivity其中Sensitivity是玩家在设置中调节的灵敏度默认1.0而RawValue取决于设备类型鼠标RawValue 鼠标移动的像素数有符号整数引擎内部会将其除以p.IE.MouseSensitivity默认0.07再应用Scale手柄摇杆RawValue 摇杆X轴的ADC采样值-32768~32767引擎会先归一化为[-1.0, 1.0]再乘以Scale键盘WASDRawValue 每帧固定增量如0.02Scale直接作用于该增量。这意味着Scale1.0对鼠标和手柄的实际影响完全不同。实测数据表明在相同物理摇杆偏移下Scale1.0的手柄转向速度约为Scale1.0鼠标的1/5。因此BaseInput.ini中通常看到AxisMappings(AxisNameTurn,KeyMouseX,Scale1.0) AxisMappings(AxisNameTurn,KeyGamepad_LeftX,Scale5.0) // 补偿手柄原始信号弱提示不要试图用Scale统一所有设备的转向速度。UE5的设计哲学是“让每种设备发挥其物理特性”鼠标应精准微调手柄应平滑大范围转向。强行用Scale拉齐会导致鼠标操作过于敏感或手柄转向迟滞。4.2 多Axis同名映射的叠加逻辑为什么“Turn”能同时响应鼠标和手柄UE5允许为同一AxisName绑定多个Key例如AxisMappings(AxisNameTurn,KeyMouseX,Scale1.0) AxisMappings(AxisNameTurn,KeyGamepad_LeftX,Scale5.0)当玩家同时移动鼠标和摇杆时引擎的处理逻辑是对每个活跃的AxisMapping独立计算其NormalizedValue然后将所有值相加最后截断到[-1.0, 1.0]区间。即FinalTurnValue Clamp(MouseX_Value Gamepad_LeftX_Value, -1.0, 1.0)这个设计的精妙之处在于它天然支持“混合输入”。例如玩家用鼠标微调视角同时用手柄摇杆进行大范围转向两者信号无缝叠加。但这也带来一个隐藏问题如果某个设备信号噪声过大如老旧鼠标抖动其微小的RawValue乘以Scale后会持续污染最终值。解决方案是在C中对每个Axis做独立滤波// 在Tick中 float MouseXFiltered FMath::FInterpTo(CurrentMouseX, NewMouseX, DeltaTime, 10.0f); float GamepadXFiltered FMath::FInterpTo(CurrentGamepadX, NewGamepadX, DeltaTime, 5.0f); FinalTurn Clamp(MouseXFiltered GamepadXFiltered, -1.0f, 1.0f);4.3 AxisConfig Section被严重低估的高级标定工具BaseInput.ini中还有一个常被忽略的Section——[AxisConfig][AxisConfig] AxisConfig(AxisNameMoveForward,DeadZone0.2,Scale1.0,Exponent1.0) AxisConfig(AxisNameTurn,DeadZone0.1,Scale1.0,Exponent2.0)它与[AxisMappings]的关系是[AxisMappings]定义“哪些设备产生哪个Axis”[AxisConfig]定义“该Axis的数值如何被后处理”。各参数物理意义如下DeadZone在归一化后的[-1.0,1.0]区间内中心多少范围被视为“无输入”。例如DeadZone0.2表示[-0.2,0.2]区间内值强制为0。这对消除手柄摇杆回中不精准的漂移至关重要。Exponent对归一化值进行幂次变换Exponent2.0时输入0.5变为0.250.8变为0.64实现“低速更灵敏高速更平缓”的手感。这是赛车游戏转向手感的核心调参项。Scale此处的Scale是[AxisMappings]中Scale的二次缩放仅作用于后处理阶段。关键陷阱[AxisConfig]中的AxisName必须与[AxisMappings]中完全一致包括大小写和下划线。曾有个项目因[AxisMappings]写Move_Forward而[AxisConfig]写MoveForward导致DeadZone完全失效手柄角色原地小幅度晃动。5. PlatformMappings实战指南跨平台输入一致性的终极防线5.1 PlatformMappings的映射本质它是一张“设备能力翻译表”[PlatformMappings]Section的典型配置[PlatformMappings] PlatformMappings(PlatformWindows,KeyGamepad_LeftX,SourceGamepad Left Thumbstick X) PlatformMappings(PlatformWindows,KeyGamepad_RightY,SourceGamepad Right Thumbstick Y) PlatformMappings(PlatformSwitch,KeyGamepad_LeftX,SourceJoycon Left Stick X) PlatformMappings(PlatformSwitch,KeyGamepad_RightY,SourceJoycon Right Stick Y)这里的Source字符串不是UE5内置枚举而是平台SDK返回的原始设备能力描述符。例如Windows平台UE5通过XInput API获取XINPUT_GAMEPAD_LEFT_THUMB_X然后在内部映射表中查找其对应的Source字符串Switch平台则通过Nintendo SDK获取HID_USAGE_JOYSTICK_X再匹配Source。这意味着如果你在新平台如PS5移植时发现Gamepad_LeftX不工作首要检查点不是你的INI文件而是UE5引擎是否已为该平台实现了Source字符串到物理设备的映射。验证方法在编辑器中启用LogInput日志启动游戏后搜索LogInput: Displaying platform mappings for你会看到引擎实际加载的完整映射表。如果某Source字符串未出现在日志中说明引擎尚未支持该设备能力。5.2 主机平台特有的PlatformMappings陷阱在主机移植中[PlatformMappings]最常引发两类问题第一类触觉反馈通道错位PlatformMappings(PlatformPS5,KeyGamepad_LeftTrigger,SourceDualSense L2 Trigger) PlatformMappings(PlatformPS5,KeyGamepad_RightTrigger,SourceDualSense R2 Trigger)这段配置看似正确但DualSense的L2/R2触发器支持自适应阻力和触觉反馈而UE5默认将Gamepad_LeftTrigger映射到传统震动马达。结果是玩家按L2时手柄震动而非阻力变化。解决方案是添加bUseAdaptiveTriggersTrue到PlatformMappingsUE5.3支持或在C中直接调用UDualSenseFunctionLibrary::SetAdaptiveTriggerEffect()。第二类触摸板输入被忽略PS5和Switch都支持触摸板但BaseInput.ini中默认没有TouchPad_*相关Key。这是因为触摸板在UE5中被归类为高级输入设备Advanced Input Device需在[ConsoleVariables]中启用[ConsoleVariables] p.IE.EnableTouchpadInput1然后在[PlatformMappings]中显式声明PlatformMappings(PlatformPS5,KeyTouchPad_Click,SourceDualSense Touchpad Click) PlatformMappings(PlatformPS5,KeyTouchPad_Touch,SourceDualSense Touchpad Touch)不启用p.IE.EnableTouchpadInput即使PlatformMappings写得再完美触摸板事件也永远不会进入UE5输入管线。5.3 动态PlatformMappings如何在运行时切换输入源某些游戏需要根据场景动态切换输入源例如VR模式下禁用鼠标仅用手柄。BaseInput.ini本身是静态配置但UE5提供了运行时API// 禁用鼠标输入 UInputSettings::Get()-bEnableMouseInput false; UInputSettings::Get()-SaveKeyBindings(); // 立即生效 // 启用手柄输入若之前被禁用 UInputSettings::Get()-bEnableGamepadInput true;但注意bEnableMouseInput等全局开关只影响设备级别的输入捕获不影响已存在的AxisMapping绑定。也就是说即使你禁用了鼠标AxisMappings(AxisNameTurn,KeyMouseX,...)这条配置依然存在只是MouseX不再产生RawValue。真正的动态切换应结合UInputSettings::Get()-GetAxisKeys(Turn)获取当前所有绑定Key再根据平台过滤。我在一个VR项目中实现“VR/非VR模式一键切换”核心逻辑是读取当前GetAxisKeys(Turn)得到{MouseX, Gamepad_LeftX}根据模式构造新的Key数组VR模式只保留Gamepad_LeftX非VR模式保留全部调用UInputSettings::Get()-RemoveAxisMapping(Turn)清除旧映射对新Key数组循环调用UInputSettings::Get()-AddAxisMapping(...)最后调用UInputSettings::Get()-SaveKeyBindings()。这套流程确保了输入映射的干净切换避免了残留绑定导致的意外行为。6. 故障排查全景图从日志到抓包的完整诊断链路6.1 日志分析读懂UE5输入系统的“黑匣子”信息当输入异常时第一步永远是开启详细日志# 在启动参数中添加 -log -Verbose -LogInput # 或在编辑器中执行控制台命令 LogInput Verbose关键日志模式及解读日志片段含义应对措施LogInput: Warning: Key Gamepad_LeftX not found in platform mappings for WindowsWindows平台未定义Gamepad_LeftX的Source映射检查[PlatformMappings]中是否有PlatformWindows条目LogInput: Displaying axis mapping for Turn: MouseX (Scale1.0), Gamepad_LeftX (Scale5.0)引擎成功加载了Turn轴的两个映射若仍无响应问题在设备驱动或硬件连接LogInput: Action Jump triggered with value 1.0 from key SpaceSpace键成功触发Jump Action若蓝图未响应检查UInputComponent是否已绑定或被销毁LogInput: Warning: Axis MoveForward has no mappingsMoveForward轴未在[AxisMappings]中声明在BaseInput.ini或DefaultInput.ini中添加对应行特别注意LogInput日志中Displaying axis mapping行会列出所有已加载的映射包括被高优先级INI覆盖的条目。这是验证你的修改是否真正生效的黄金标准。6.2 设备级抓包当UE5日志沉默时的终极手段有时日志显示一切正常但输入就是不工作。这时必须下沉到操作系统层抓包。以Windows为例鼠标/键盘使用Microsoft Message Analyzer或Wireshark需安装USBPcap驱动捕获HID报告描述符Xbox手柄使用xinputtest命令行工具运行xinputtest -v实时查看原始XInput数据包PS5 DualSense使用ds4windows的调试模式查看HID Usage Page和Usage ID。抓包目标是验证操作系统是否真的向UE5发送了预期信号例如当你按下手柄左摇杆时抓包应显示Usage ID: 0x30X轴和Usage ID: 0x31Y轴的数值变化。如果抓包看到数值变化但UE5日志无Action triggered说明问题在UE5的设备抽象层如果抓包本身无数据则是驱动或硬件问题。我在排查一个“Switch Pro手柄在UE5中Y轴反向”问题时抓包发现Switch SDK返回的Y轴原始值是-32768~32767但UE5内部期望32767~-32768即正向为上。最终解决方案是在[PlatformMappings]中为Y轴添加负号PlatformMappings(PlatformSwitch,KeyGamepad_LeftY,SourceJoycon Left Stick Y,bInvertTrue)6.3 配置文件冲突的可视化排查法当多个INI文件存在同名配置时手动比对极易出错。我开发了一个Python脚本已开源在GitHub可自动生成冲突报告# 伪代码逻辑 configs [BaseInput.ini, DefaultInput.ini, Windows/Input.ini] all_mappings {} for config in configs: for section in parse_ini(config): if section.name in [ActionMappings, AxisMappings]: for mapping in section.items: key f{section.name}:{mapping.ActionName or mapping.AxisName} if key not in all_mappings: all_mappings[key] [] all_mappings[key].append((config, mapping)) # 输出冲突报告 for key, mappings in all_mappings.items(): if len(mappings) 1: print(fCONFLICT {key}:) for config, mapping in mappings: print(f {config} - {mapping.Key})运行后输出类似CONFLICT AxisMappings:Turn: BaseInput.ini - MouseX DefaultInput.ini - MouseX, Gamepad_LeftX Windows/Input.ini - MouseX, Gamepad_LeftX, TouchPad_X这让你一眼看清哪个配置文件在哪个层级覆盖了什么避免盲目修改。7. 生产环境最佳实践让BaseInput.ini成为团队协作的基石7.1 版本控制策略为什么不能把DefaultInput.ini提交到GitBaseInput.ini作为引擎基线应始终提交到Git。但DefaultInput.ini和平台专属INI如Windows/Input.ini必须加入.gitignore。原因有三玩家个性化设置DefaultInput.ini常被玩家手动修改以适配个人习惯提交到仓库会覆盖用户设置平台差异巨大Windows/Input.ini和Console/Input.ini内容完全不同强制统一会导致主机版本无法构建编辑器自动生成UE5编辑器在首次启动时会根据当前平台自动生成DefaultInput.ini其内容包含平台特定的默认键位。正确做法是在仓库中提供DefaultInput.ini.template模板文件其中只包含项目必需的Action/Axis声明不含具体Key绑定。团队成员首次克隆后运行GenerateDefaultInputIni.bat脚本内容为copy DefaultInput.ini.template DefaultInput.ini再在编辑器中手动配置。7.2 输入配置的自动化测试用CI保障每次提交不破坏输入在CI流水线中加入输入配置验证可避免低级错误。我们使用的测试用例包括语法验证用正则检查所有ActionMappings行是否符合(ActionName.*,Key[^,],bShift.*$)格式Key存在性检查遍历[ActionMappings]和[AxisMappings]中的所有Key确认其在EKeys枚举中存在通过解析UE5源码中的InputCoreTypes.h跨平台一致性检查确保所有[PlatformMappings]中声明的Key在[ActionMappings]和[AxisMappings]中均有对应条目。一个简单的Bash脚本示例# 检查BaseInput.ini中是否存在未声明的Key grep -oP Key\K[^,)] Engine/Config/BaseInput.ini | sort -u | while read key; do if ! grep -q EKeys::$key Engine/Source/Runtime/InputCore/Public/InputCoreTypes.h; then echo ERROR: Unknown key $key in BaseInput.ini exit 1 fi done7.3 我的个人经验三个永远要做的检查清单经过数十个项目锤炼我形成了输入配置修改后的“三必查”清单必查日志首行修改后首次启动紧盯LogInput: Displaying axis mapping for XXX这一行确认你修改的Axis/Action确实出现在列表中。这是最快速的“生效验证”。必查修饰键组合如果修改了bShiftTrue等配置务必用“ShiftKey”和“Key alone”两种方式测试确认逻辑符合设计。曾有项目因忘记测试单独按键导致玩家无法在不按Shift时跳跃。必查主机平台映射即使当前只开发PC版每次修改[PlatformMappings]后都打开Console/Input.ini或对应主机INI确认没有遗漏PlatformConsole的条目。主机移植时90%的输入问题根源都在PC开发阶段埋下的映射缺失。最后分享一个小技巧在BaseInput.ini顶部添加注释块记录每次重大修改的日期、作者和原因; 2024-06-15 by ZhangSan: Add Gamepad triggers for PS5 adaptive feedback ; Reason: Marketing requires haptic feedback on L2/R2 for boss fights ; Impact: Requires UE5.3, breaks compatibility with 5.3这份注释比任何Wiki文档都可靠因为它是和代码一起演进的活历史。当你半年后面对一个陌生的bInvertTrue配置时这行注释就是最好的上下文。