1. 先搞清楚这个项目要解决什么问题
把"打印"和"输入"放在同一个标题里，乍一看像两个不相关的知识点，但实际做项目时它们经常一起出现：你想确认按键有没有触发、数值有没有传对、Mapping Context 有没有加载，都需要调试输出；而输入绑定本身，又是很多 C++ 新手一上来就卡壳的地方。这篇文章想聊的，就是 UE/C++ 里"怎么把调试信息打出来"和"怎么用增强输入系统把按键变成角色动作"这两件事。
适合谁来参考？如果你是刚开始接触 UE C++，或者之前一直用蓝图，终于想换个姿势写输入；又或者你已经写了不少传统 Axis/Action Mapping，但对 Enhanced Input 这套东西还没串起来，那这篇正合适。我会把代码、配置、坑点拆开讲，尽量让一个没碰过增强输入的人也能照着写出来。
先说结论：增强输入系统不难，真正难的是理解它的几个角色——InputAction、InputMappingContext、EnhancedInputComponent 和 LocalPlayerSubsystem。很多教程只给了一段能跑的代码，但没解释为什么要这样拼。我这里会把每一块负责什么、为什么放在这个位置说清楚，后面遇到问题也知道去哪儿查。
2. C++里打印调试信息的几种方法
UE 里打印调试信息，核心其实就是两拨：打日志的和打屏幕的。日志适合长期记录和排查，屏幕适合开发阶段一眼看状态。我见过不少人在 C++ 里写了UE_LOG却什么也没看到，或者在打包后看不到屏幕信息就以为代码没生效。这一节把方法和坑点一次性讲透。
2.1 UE_LOG：最常用的日志输出
UE_LOG的完整用法是四个参数：Category（日志类别）、Verbosity（级别）、Format（格式串）、变量列表。最简单的是直接用LogTemp：
UE_LOG(LogTemp, Log, TEXT("角色当前坐标: %s"), *GetActorLocation().ToString());这里有一个细节：%s对应的是TCHAR*，而FString不能直接传进去，必须取*FString。很多萌新写TEXT("坐标: %s"), GetActorLocation().ToString()，然后编译报错或者输出乱码，就是因为少了这颗星。
推荐的做法不是所有地方都塞LogTemp，而是为你的项目定义专属 Category。在 .cpp 文件顶部加一行宏：
DEFINE_LOG_CATEGORY_STATIC(LogMyDemo, Log, All);然后这样用：
UE_LOG(LogMyDemo, Warning, TEXT("[%s] 输入系统已初始化，Controller: %s"), *GetName(), Controller ? *Controller->GetName() : TEXT("nullptr"));Verbosity 从小到大是Fatal、Error、Warning、Display、Log、Verbose、VeryVerbose。默认 Output Log 窗口会过滤掉Verbose以下的内容，所以如果你写了UE_LOG(LogMyDemo, Verbose, TEXT("..."))没看到，不一定是代码没跑，很可能是级别不够高。开发期我一般用Warning和Display，既明显又不会被过滤。
格式化符也要记牢：%d是整数、%f是浮点、%s是字符串。浮点类型最好转成 FString 再打，或者用%.2f控制精度，否则输出一长串小数会刷屏。
2.2 AddOnScreenDebugMessage：打印到屏幕上
UE_LOG只在 Output Log 里看，调试角色移动时很不直观。更舒服的方式是直接打印到游戏画面中央，用GEngine的调试函数：
if (GEngine) { GEngine->AddOnScreenDebugMessage(-1, 2.0f, FColor::Green, TEXT("按键已触发")); }第一个参数是消息 Key。传-1表示每次新开一行，很多条消息堆在一起很快就乱了。更好的方式是传一个整数 Key，相同 Key 的消息会覆盖之前的内容，适合表示"某个状态的数值在实时变化"：
if (GEngine) { GEngine->AddOnScreenDebugMessage(101, 0.0f, FColor::Yellow, FString::Printf(TEXT("MoveForward Value: %.2f"), Value.Get<float>())); }这条消息会一直显示，直到 Duration 到了。0.0f表示不消失，直到被下一帧覆盖或清屏。这个写法在调整输入手感、查看按键数值时特别有用，比日志直观得多。
2.3 PrintString、常见坑和实用技巧
蓝图里的PrintString节点，在 C++ 里可以直接调UKismetSystemLibrary::PrintString。它本质上是把日志和屏幕打印封装在一起，适合快速验证某个事件有没有进来：
UKismetSystemLibrary::PrintString(this, TEXT("Jump Start"), true, true, FColor::Cyan, 2.0f);最后一个参数可以传 Key，具体用法和AddOnScreenDebugMessage一样。注意PrintString尽量在事件触发时调用，不要在Tick里每帧打，不然屏幕会被刷爆，还影响性能。
关于屏幕调试信息，有两个高频坑要提醒。
第一个是控制台命令DisableAllScreenMessages。你可能手滑在控制台输入过，它会把所有AddOnScreenDebugMessage和PrintString的屏幕输出关掉，但日志仍然在。遇到"屏幕不打印"第一反应应该是再输入一次EnableAllScreenMessages确认开关状态。
第二个是GEngine为空。像APawn::BeginPlay之前、静态构造函数里、模块启动阶段，都不一定能拿到GEngine指针。所以打印前加if (GEngine)判断是个好习惯，不仅防空指针，还避免因为打印导致崩溃。
3. 增强输入系统核心概念拆解
UE4 时代大家习惯在 Project Settings 里配 Axis Mappings 和 Action Mappings，然后在SetupPlayerInputComponent里用BindAxis和BindAction。这套方案简单，但项目一旦复杂就会出现问题：角色在 UI 界面里还能乱动、多个操作模式互相抢按键、手柄死区要么去不了抖要么太迟钝。增强输入系统（Enhanced Input）就是为了解决这些问题出来的。
你可以把整个增强输入想象成一块"可插拔的接线板"。物理按键是墙上的插座，而角色想要执行的动作是电器。传统输入是出厂时就用胶带绑死的线；增强输入则允许你随时换接线方式、给电流加稳压器、规定什么时候通电。这里拆开看它的四个核心角色。
3.1 InputAction 与 InputMappingContext
UInputAction是一个"动作定义"。它不关心具体是哪个键触发，只描述这个动作的输出值类型。比如IA_Look的值类型是Axis2D，用来接收鼠标的 XY 偏移；IA_Jump的值类型是Digital (bool)，按下就是 1，松开就是 0。这个抽象最大的好处是：同一个动作可以被键盘、手柄、触摸屏共用，物理设备变了，逻辑不用改。
UInputMappingContext是一个"映射集合"。它负责把真实按键（FKey）和UInputAction连起来，同时还能给映射添加Modifiers（修饰器）和Triggers（触发器）。修饰器解决的是"数值加工"问题，比如把鼠标 X 轴反向、给摇杆加死区、把按键值乘以 -1；触发器解决的是"什么时候算按下"的问题，比如单击、双击、长按、松手。这种分层设计是传统输入完全不具备的。
我经常拿一个 Mapping Context 类比"一套操作方案"：你站在地上时是一套，开车时是另一套，打开菜单时可能空手套。不同 Context 之间可以动态切换，也可以叠加，靠优先级决定谁说了算。
3.2 EnhancedInputComponent 与 LocalPlayerSubsystem
UEnhancedInputComponent是绑定的入口。传统UInputComponent会根据按键名去分发，而EnhancedInputComponent直接绑定到UInputAction资产上，通过UInputAction间接触发回调。这样键盘从 W 改成手柄左摇杆，C++ 侧一行代码都不用改。
UEnhancedInputLocalPlayerSubsystem负责管理 Mapping Context 的增删和优先级。你需要在玩家本地控制器里拿到这个子系统，然后把默认的 Mapping Context 加进去。注意它挂在ULocalPlayer上，不是挂在 Pawn 或者 World 上，这是很多新人搞混的地方。
3.3 和传统输入对比，什么时候选哪种
传统输入适合极小型原型，或团队里没人愿意翻新代码的历史项目。如果你想快速做一个只能按空格跳一跳的测试，传统 Action Mapping 完全够用。但只要你开始做移动、视角、跳跃、交互、菜单、对话多套模式，或者想支持手柄和键鼠无缝切换，增强输入是当下更合适的选择。
这里做个简单对比：
| 对比项 | 传统输入 | 增强输入 |
|---|---|---|
| 绑定对象 | 按键名/轴名 | InputAction 资产 |
| 模式切换 | 手动 Enable/Disable 轴 | MappingContext 优先级 |
| 数值处理 | 几乎没有 | 支持修饰器和触发器 |
| 手柄支持 | 基础可用 | 更完善 |
| 调试体验 | 一般 | 可单独调试每个 Action |
再多说一句，官方模板这几年已经默认使用增强输入，新项目再继续用传统 Axis/Action 反而要自己费劲做兼容。与其等到项目写到一半再迁移，不如现在就按新体系的思路去组织输入层。
4. 实操：C++绑定增强输入系统的完整流程
这一节是核心。我会从空项目开始，走过每一步。因为目标是"简单创建"，所以我尽量用最少的资产和代码，先跑通一个能移动、能跳跃、能转视角的角色。
4.1 环境准备：插件、模块依赖与头文件
如果没有启用增强输入插件，你会遇到一堆"找不到类型"的编译错误。打开 Plugins 面板，搜索Enhanced Input，把它勾上并重启编辑器。
然后在项目的.Build.cs文件里加上模块依赖：
PublicDependencyModuleNames.AddRange(new string[] { "Core", "CoreUObject", "Engine", "InputCore", "EnhancedInput" });EnhancedInput这个模块名不能漏。漏了之后编译时会提示找不到UEnhancedInputComponent、UEnhancedInputLocalPlayerSubsystem这些类型。加上依赖后，重新生成工程文件，打开编辑器。
4.2 创建 InputAction 和 InputMappingContext
在 Content Browser 里右键，选择Input -> Input Action，创建以下动作：
IA_MoveForward：Value Type 选Axis1D (float)，用来接收前后移动。IA_MoveRight：Value Type 选Axis1D (float)，用来接收左右移动。IA_Look：Value Type 选Axis2D (Vector2D)，用来接收视角。IA_Jump：Value Type 选Digital (bool)，用来接收跳跃。
再右键创建Input -> Input Mapping Context，命名为IMC_Default。
往IMC_Default里加映射：
| 按键 | 绑定的 Action | 修饰器/说明 |
|---|---|---|
| W | IA_MoveForward | 无，正向 +1 |
| S | IA_MoveForward | 添加Negate修饰器，反向 -1 |
| D | IA_MoveRight | 无 |
| A | IA_MoveRight | 添加Negate修饰器 |
| Mouse XY | IA_Look | 无 |
| SpaceBar | IA_Jump | 无 |
Negate修饰器加在映射上，加在哪里？选中映射后，在 Details 面板的Modifiers数组里添加Negate。这样 S 键触发同一个IA_MoveForward时，输出值会被翻转成负数。一套 C++ 逻辑就同时支持了正反两个方向。
4.3 在角色类中声明输入引用
创建一个 C++ Character 子类，比如AMyCharacter。在头文件里声明UInputAction和UInputMappingContext的引用，并用UPROPERTY暴露到编辑器：
#pragma once #include "CoreMinimal.h" #include "GameFramework/Character.h" #include "MyCharacter.generated.h" class UInputAction; class UInputMappingContext; UCLASS() class MYPROJECT_API AMyCharacter : public ACharacter { GENERATED_BODY() public: virtual void BeginPlay() override; virtual void SetupPlayerInputComponent(UInputComponent* PlayerInputComponent) override; protected: void MoveForward(const FInputActionValue& Value); void MoveRight(const FInputActionValue& Value); void Look(const FInputActionValue& Value); void StartJump(); void StopJump(); UPROPERTY(EditAnywhere, BlueprintReadOnly, Category = "Input") TObjectPtr<UInputAction> MoveForwardAction; UPROPERTY(EditAnywhere, BlueprintReadOnly, Category = "Input") TObjectPtr<UInputAction> MoveRightAction; UPROPERTY(EditAnywhere, BlueprintReadOnly, Category = "Input") TObjectPtr<UInputAction> LookAction; UPROPERTY(EditAnywhere, BlueprintReadOnly, Category = "Input") TObjectPtr<UInputAction> JumpAction; UPROPERTY(EditAnywhere, BlueprintReadOnly, Category = "Input") TObjectPtr<UInputMappingContext> DefaultMappingContext; };之后在蓝图子类或直接在 Character 的 Class Defaults 里，把MoveForwardAction这些属性指到你创建好的资产。这种"蓝图里拖资产、C++ 里消费资产"的组合拳很实用，C++ 不用硬编码资源路径，策划也能不碰代码去调映射。
4.4 挂载 MappingContext
在.cpp的BeginPlay里，将IMC_Default注册给本地玩家子系统：
#include "MyCharacter.h" #include "EnhancedInputComponent.h" #include "EnhancedInputSubsystems.h" #include "InputActionValue.h" #include "Kismet/GameplayStatics.h" void AMyCharacter::BeginPlay() { Super::BeginPlay(); if (APlayerController* PC = Cast<APlayerController>(GetController())) { if (UEnhancedInputLocalPlayerSubsystem* Subsystem = ULocalPlayer::GetSubsystem<UEnhancedInputLocalPlayerSubsystem>(PC->GetLocalPlayer())) { Subsystem->AddMappingContext(DefaultMappingContext, 0); } } }AddMappingContext的第二个参数是优先级。数字越大越优先，多个 Context 都想用同一个按键时，高优先级会"吃掉"输入。普通情况下填 0 就够，进入 UI、对话状态时再加更高优先级的 Context 去覆盖默认操作。
为什么要放在BeginPlay而不是构造函数？因为构造函数阶段还没有 Controller，拿不到本地玩家子系统。如果你担心 Pawn 生成时 Controller 还没 Possess 完整，可以在PossessedBy或PawnClientRestart里挂载。对于单机 Demo，BeginPlay实测足够稳定。
4.5 绑定输入回调
SetupPlayerInputComponent是关键入口。它收到的是UInputComponent，但我们要先转换成UEnhancedInputComponent再绑定：
void AMyCharacter::SetupPlayerInputComponent(UInputComponent* PlayerInputComponent) { Super::SetupPlayerInputComponent(PlayerInputComponent); if (UEnhancedInputComponent* EnhancedInput = Cast<UEnhancedInputComponent>(PlayerInputComponent)) { EnhancedInput->BindAction(MoveForwardAction, ETriggerEvent::Triggered, this, &AMyCharacter::MoveForward); EnhancedInput->BindAction(MoveRightAction, ETriggerEvent::Triggered, this, &AMyCharacter::MoveRight); EnhancedInput->BindAction(LookAction, ETriggerEvent::Triggered, this, &AMyCharacter::Look); EnhancedInput->BindAction(JumpAction, ETriggerEvent::Started, this, &AMyCharacter::StartJump); EnhancedInput->BindAction(JumpAction, ETriggerEvent::Completed, this, &AMyCharacter::StopJump); } }ETriggerEvent是理解增强输入的关键之一：
Started：动作第一次触发，适合跳跃、举枪这类瞬间事件。Triggered：动作持续触发，适合移动、视角、按住蓄力。Completed：动作结束，适合松手、放枪、停止跳跃。Canceled：动作被打断，比如长按中途移动了镜头。
跳跃绑定两个事件，StartJump和StopJump，配合 Character 自带的Jump()和StopJumping()，手感会比每次Triggered都调Jump()干净得多。
4.6 在回调里读取值并驱动角色运动
回调函数接收const FInputActionValue& Value，用模板方法Get<T>()取出实际数值：
void AMyCharacter::MoveForward(const FInputActionValue& Value) { float Scale = Value.Get<float>(); AddMovementInput(GetActorForwardVector(), Scale); } void AMyCharacter::MoveRight(const FInputActionValue& Value) { float Scale = Value.Get<float>(); AddMovementInput(GetActorRightVector(), Scale); } void AMyCharacter::Look(const FInputActionValue& Value) { FVector2D LookVector = Value.Get<FVector2D>(); AddControllerYawInput(LookVector.X); AddControllerPitchInput(-LookVector.Y); } void AMyCharacter::StartJump() { Jump(); } void AMyCharacter::StopJump() { StopJumping(); }这里有两个易错点。
第一，Value.Get<T>必须和UInputAction的 Value Type 匹配。IA_MoveForward是Axis1D，你就不能用Get<FVector2D>()，否则会发生断言。所以定义资产时想清楚每个 Action 是什么形状的数值。
第二，鼠标 Y 轴通常是反的，所以Look里AddControllerPitchInput要取负号，否则往上推鼠标会往下看。这个数值方向问题在传统输入里也常见，不要等对手感不满意时才发现。
4.7 不用编辑器，纯代码创建输入资源
如果你不想在 Content Browser 里手动建资产，也可以在 C++ 运行时动态创建。原理其实和蓝图资产一样，只是多了NewObject：
UInputAction* JumpActionAsset = NewObject<UInputAction>(this); JumpActionAsset->ValueType = EInputActionValueType::Boolean; UInputMappingContext* IMC = NewObject<UInputMappingContext>(this); IMC->MapKey(JumpActionAsset, EKeys::SpaceBar);需要加修饰器时，拿到MapKey返回的映射引用往里塞：
FEnhancedActionKeyMapping& SKeyMapping = IMC->MapKey(MoveForwardActionAsset, EKeys::S); SKeyMapping.Modifiers.Add(NewObject<UInputModifierNegate>());但这种"边运行边创建"的方式只适合做小测试。生产项目我仍然推荐在编辑器里用资产配置，因为资产可以交给设计师调，纯代码写死在程序里，后续想改键位就要重新编译，完全失去了增强输入系统灵活性的意义。
5. 常见问题与排查实录
讲完实现，再看几个真实开发里最容易遇到的问题。这些问题我基本都踩过，有些看起来莫名其妙，实际原因特别简单。
5.1 编译失败，找不到 EnhancedInput 模块
报错多半是Unable to find type 'UEnhancedInputComponent'、UEnhancedInputLocalPlayerSubsystem未定义，或者头文件找不到。最常见的根因就是.Build.cs没加"EnhancedInput"。加完之后记得关闭 IDE，重新生成项目文件再编译，否则编辑器还可能用旧的模块列表。
5.2 绑定写好了，但按按键没反应
这是最让人崩溃的一类问题。排查顺序我建议固定下来：
- 先确认插件已经启用。插件没启用，连编译都过不了，但如果项目里只有蓝图脚本用增强输入，C++ 代码里没有 include 相关头文件，可能编辑器也不会报错。
- 打印
GetController()是否为空。如果BeginPlay时 Pawn 还没被 Possess，AddMappingContext就加不进去。可以改成在PossessedBy里挂载，或者用一个短延时GetWorldTimerManager延后执行。 - 打印
DefaultMappingContext是否为空。因为在蓝图里忘了赋值，就会卡在空指针，但代码可能因为空引用保护而没有任何表现，看起来就像"按键没反应"。 - 确认映射里绑定的按键，和你在物理键盘上按的键一致。这个听起来弱智，但改完映射忘了保存、改了资产没重新加载，也是真实会发生的事。
5.3 调试信息在屏幕上消失了
刚才提过DisableAllScreenMessages控制台命令，这是头号嫌疑。另一个原因是你的AddOnScreenDebugMessage调用在GEngine还没有初始化时执行，比如在UObject的构造函数里。屏幕上没有，就去看日志，日志里也没有，再看看是不是 Verbosity 等级太低或模块没启动。
还有一个常见场景：UKismetSystemLibrary::PrintString的bPrintToScreen和bPrintToLog，有些人只把bPrintToLog勾上，屏幕当然不显示。检查这两个参数。
5.4 回调重复触发、数值类型不对
跳跃用ETriggerEvent::Triggered就会每帧都触发，看起来像跳了好几下。解决方法是用Started和Completed配对，让Jump()只在按下的瞬间调用。移动则必须用Triggered，因为你要持续读取摇杆数值。
数值类型不对是最隐蔽的问题。如果你建IA_Jump时选的是 Digital，但在 C++ 里用Value.Get<FVector2D>()，运行时会触发断言，甚至直接崩溃。我会写一小段打印逻辑，把 Action 的 ValueType 和回调里使用的类型打印出来对比。这也是为什么我在项目里会定义 Log Category，方便看到这类信息。
5.5 输入系统排查速查表
| 现象 | 可能原因 | 处理方式 |
|---|---|---|
| 编译失败 | 缺少 EnhancedInput 模块 | .Build.cs添加依赖并重新生成 |
| 按键无反应 | MappingContext 没挂上 | 打印 Controller 和 Subsystem 是否为空 |
| 按键无反应 | 资产没赋值 | 检查 UPROPERTY 在蓝图里是否指向正确资产 |
| 屏幕不打印 | DisableAllScreenMessages | 控制台输入 EnableAllScreenMessages |
| 屏幕不打印 | GEngine 为空 | 在非启动阶段调用，加空判断 |
| 效果持续触发 | Triggered 用错 | 瞬间动作改用 Started/Completed |
| 断言崩溃 | Get 和值类型不匹配 | 检查 InputAction 的 ValueType |
6. 我的实际使用体会
经常有人问，传统输入明明也能跑，非得学增强输入是不是形式主义？我的体验是：真正开始做多套操作模式后，差距非常明显。以前做菜单界面屏蔽角色输入，要在代码里写一堆 EnableInput、DisableInput 或对按键名做黑名单；现在只需要动态加一个高优先级 MappingContext，把收到的事件吞掉就行，输入逻辑干净很多。
一个让我吃过亏的习惯是，增删 MappingContext 要记得成对出现。单机 Demo 在BeginPlay里加一次，不删也没关系；但如果你做角色暂停、死亡、切换控制权，只加不删，旧 Context 会一直挂在那里，按键行为会变得神出鬼没。最佳实践是在每个需要输入的地方都写清晰的生命周期：加的时候记下时机，退场或禁用时用RemoveMappingContext移除。
另一个习惯是别急着在 C++ 里写死所有映射。先把UInputAction和UInputMappingContext做成资产，再通过UPROPERTY暴露，这样后期改键位、调死区，都不需要动 C++。我也是从一次"改一个按键必须发版"的教训里学到的，输入这种跟手感强相关的东西，一定要让项目上线后还能被人力快速调整。
如果你刚开始接触这套系统，建议不要直接抄完代码就关页面。先拿纸把 InputAction、MappingContext、EnhancedInputComponent、LocalPlayerSubsystem 这四个东西的关系画一遍，再跑一遍那个最简单的跳台原型。多跑几次之后，你会发现增强输入系统其实是在帮你把"物理设备"和"游戏意图"分开，而 C++ 只是负责在中间架一座桥。
