做 UE5 项目的时候窗口右上角那三个按钮——最小化、最大化、关闭再加上一个还原——看着是最不起眼的一环真要自己接管坑比做一套背包系统还多。引擎默认给你的是操作系统级别的那套标题栏你没法在上面画自己的 UI一旦把标题栏去掉换成无边框窗口按钮得自己画、拖动得自己写、关闭得自己拦甚至连最小化这个动作在蓝图里都找不到现成节点。这篇东西就是把我自己在几个 UE5 项目里折腾 UE5 窗口设置、最小化、最大化、关闭和还原的完整过程整理出来从需求拆解、模块配置、C 封装、UMG 对接一直到打包后才会暴露的那些玄学问题全部摊开讲。适合已经能跑起来 UE5 工程、想给自己的游戏做一套自定义窗口控制的朋友也适合只是想搞清楚为什么我点了最小化把整个编辑器都收起来了的新手。1. 先把需求拆清楚UE5 里的窗口四件套到底指什么1.1 引擎默认窗口行为的边界在哪里很多人第一次做窗口控制是因为策划提了一句游戏要能窗口化玩家点右上角那个叉要弹确认框。然后你打开 UMG翻遍蓝图节点列表发现跟窗口有关的只有Get Game User Settings、Set Screen Resolution、Set Fullscreen Mode这寥寥几个最小化和最大化一个都搜不到。这不是你搜错了而是引擎压根没打算把系统的窗口句柄通过蓝图暴露出来。UE5 的窗口体系是分层最底层是操作系统给的窗口句柄中间层是 Slate 的SWindow/FGenericWindow最上面是UGameViewportClient。游戏的渲染画面是被塞进一个 Slate 顶层窗口里显示的GEngine-GameViewport-GetWindow()拿到的就是那个顶层窗口。蓝图能碰到的UGameUserSettings只管全屏还是窗口化、分辨率多少、垂直同步开不开这类渲染与显示配置它管不到把这个窗口收进任务栏这种窗口管理动作。所以核心结论很清楚分辨率、全屏模式走 GameUserSettings最小化、最大化、还原、真正的窗口关闭必须下沉到SWindow这一层。这个边界一开始就想明白后面架构选型会省很多来回。还有一个特别容易被忽略的点在编辑器里按 Play 进入的 PIE 模式游戏视口是嵌在编辑器主窗口里的GetWindow()返回的其实是编辑器自己的顶层窗口。这时候你调最小化收起来的是整个编辑器。这个现象几乎每个人都会踩一次后面第 2 章会专门讲怎么规避。1.2 三条实现路线的对比与选型建议实现窗口控制往下走有三条路各自适合的场景差别挺大我先把它们摆在一起对比你再决定走哪条。实现路线覆盖功能是否需要写 C编辑器内可测推荐场景纯 GameUserSettings只能切全屏/窗口化、改分辨率否是但效果受限设置菜单里的显示选项C 封装 SWindow 并暴露给蓝图最小化、最大化、还原、隐藏、位置控制全覆盖是量不大需 Standalone自定义标题栏的 PC 游戏平台原生 API如 Win32ShowWindow全部且能拿到系统原生的动画效果是需要平台宏隔离需打包对最小化动画、任务栏行为有严格要求第一条路几乎所有项目都会用因为设置界面的分辨率下拉列表绕不开UGameUserSettings。第二条路是我最推荐的写一个UBlueprintFunctionLibrary子类把SWindow的几个方法包一层编译一次之后关卡蓝图和 UMG 里都能直接拖节点用团队里不写 C 的同事也能接。第三条路是兜底方案只在发现SWindow::Minimize()在某个 Windows 版本上表现不对时才启用因为一旦用了原生 API你就得写#if PLATFORM_WINDOWS宏把代码隔离开还要处理AllowWindowsPlatformTypes.h的包含顺序维护成本明显高一截。选型背后有个判断原则值得说一下能用引擎抽象层解决的就不要碰平台原生 API因为引擎帮你处理了 DPI 缩放、多显示器坐标、输入法窗口跟随这些琐事。我一开始图省事直接调 Win32 的ShowWindow(GetActiveWindow(), SW_MINIMIZE)结果在 150% 缩放的屏幕上窗口还原后坐标整个偏掉排查了整整一个下午才发现是坐标空间没换算。后来老老实实回到SWindow一切都正常了。2. 动手前的工程准备模块、配置与测试环境2.1 Build.cs 与模块依赖先把依赖配好不然编译会给你一堆找不到 SWindow 定义的报错新手很容易卡在这一步就放弃了。打开你项目的Source/你的项目名/你的项目名.Build.cs在PublicDependencyModuleNames里补上三个模块。PublicDependencyModuleNames.AddRange(new string[] { Core, CoreUObject, Engine, InputCore, UMG, // 用 UserWidget 相关的类型时需要 Slate, // SWindow、FSlateApplication 在这里 SlateCore // FSlateApplication 的很多基础类型在这一层 });这里有个细节值得强调Slate和SlateCore的区别很多人搞不清加错了就报不完整类型。简单记法是SlateCore放的是基础数据结构比如FSlateBrush、FSlateRect、FSlateApplication的声明Slate放的是具体控件实现比如SWindow、SButton、SVerticalBox。你要用SWindow两个都得加而且Slate必须放在SlateCore之后AddRange会自动处理顺序不用太担心。另外如果你打算把窗口控制做成一个独立的插件以后复用把这些模块加到插件的Build.cs里就行别塞到主工程不然以后想摘出来会很痛苦。我自己就吃过这个亏第一版把代码写进了主工程的 GameMode 里后来第二个项目想复用只能把代码一段段抠出来重写。2.2 用 Standalone 模式做测试别在 PIE 里瞎折腾这一条是我强烈建议养成习惯的窗口相关的功能一律用 Standalone 模式或者打包版测试不要在 PIE 里试。原因前面提过PIE 的游戏视口是嵌在编辑器窗口里的GetWindow()拿到的是编辑器主窗口。你在 PIE 里调最小化收起来的是整个编辑器调最大化编辑器变成全屏调位置移动编辑器窗口开始乱跑。更烦的是ApplyResolutionSettings在 PIE 下基本是个空操作你怎么点分辨率都不变很容易误判成代码写错了。在编辑器顶部工具栏的 Play 按钮旁边有个下拉箭头把播放模式改成Standalone Game引擎会独立拉起一个进程和窗口这时候行为就和打包版一致了。虽然每次启动慢一点但能省掉大量到底是代码问题还是环境问题的纠结。顺带说一句代码里最好还是加个编辑器判断防止同事在 PIE 里误点导致编辑器被最小化体验非常糟糕。#if WITH_EDITOR // PIE 下 GameViewport 的顶层窗口就是编辑器主窗口操作它会影响编辑器 if (GIsEditor) { UE_LOG(LogTemp, Warning, TEXT([WindowControl] PIE 环境不支持真实窗口操作请使用 Standalone 模式)); return false; } #endif这个判断是编译期的打包后这段代码会被整个裁掉不会有任何运行时开销放心加。2.3 窗口模式的三个枚举值与 ini 落地字段EWindowMode只有三个值但它们的实际表现差异极大很多人做到一半才发现自己选错了模式。枚举值整数实际表现有系统边框任务栏可见能否最小化Fullscreen0独占全屏切换时可能短暂黑屏否否无意义WindowedFullscreen1无边框全屏切换流畅覆盖任务栏否否无意义Windowed2普通窗口带系统标题栏是是可以这里的选择逻辑很直白只要玩家需要点最小化就必须处在Windowed模式。因为独占全屏和无边框全屏下窗口本来就铺满了整个屏幕最小化在语义上是不成立的部分平台甚至会直接忽略这个调用。所以我的做法是在最小化函数里先检查当前的模式不是Windowed就先切回Windowed再最小化同时把原来的模式记下来等还原的时候再切回去。这些状态最终都会落到Saved/Config/Windows/GameUserSettings.ini里理解这些字段对排查为什么打包后默认是全屏这类问题特别有用。[/Script/Engine.GameUserSettings] bUseVSyncFalse ResolutionSizeX1600 ResolutionSizeY900 LastUserConfirmedResolutionSizeX1600 LastUserConfirmedResolutionSizeY900 WindowPosX-1 WindowPosY-1 FullscreenMode2 LastConfirmedFullscreenMode2 PreferredFullscreenMode2注意WindowPosX和WindowPosY给-1是引擎的一个约定表示位置交给系统决定通常表现为居中。你如果手动写了个具体坐标换了台显示器就可能出现在屏幕外面这个坑后面第 5 章会详细讲怎么兜底。3. 核心实现最小化、最大化、还原、关闭的完整代码3.1 封装一个蓝图可调的窗口控制函数库我把四个动作全部塞进一个UBlueprintFunctionLibrary里原因很简单函数库不需要实例、不需要挂载、任何蓝图都能直接调是最省心的分发方式。先写头文件。// WindowControlBPLibrary.h #pragma once #include CoreMinimal.h #include Kismet/BlueprintFunctionLibrary.h #include WindowControlBPLibrary.generated.h UCLASS() class MYGAME_API UWindowControlBPLibrary : public UBlueprintFunctionLibrary { GENERATED_BODY() public: // 最小化非窗口化模式会先切回窗口化 UFUNCTION(BlueprintCallable, Category WindowControl) static bool MinimizeGameWindow(); // 最大化已经是最大化状态时自动还原方便做成一个按钮切换 UFUNCTION(BlueprintCallable, Category WindowControl) static bool MaximizeGameWindow(); // 还原从最小化或最大化回到普通窗口并恢复之前的全屏模式 UFUNCTION(BlueprintCallable, Category WindowControl) static bool RestoreGameWindow(); // 关闭游戏 UFUNCTION(BlueprintCallable, Category WindowControl) static void CloseGameWindow(bool bIgnorePlatformRestrictions false); // 查询状态UI 上要显示不同图标时会用到 UFUNCTION(BlueprintPure, Category WindowControl) static bool IsGameWindowMinimized(); UFUNCTION(BlueprintPure, Category WindowControl) static bool IsGameWindowMaximized(); private: static TSharedPtrSWindow GetGameWindow(); // 记住最小化之前处于什么全屏模式还原时回写 static EWindowMode CachedWindowMode; };CachedWindowMode这个静态变量是整个设计的核心。因为最小化会把模式从无边框全屏降级到窗口化如果不记住原值玩家还原后就永远停在窗口化体验上会觉得游戏把我设置弄丢了。再看实现文件。// WindowControlBPLibrary.cpp #include WindowControlBPLibrary.h #include Engine/Engine.h #include Engine/GameViewportClient.h #include GameFramework/GameUserSettings.h #include Framework/Application/SlateApplication.h #include Kismet/KismetSystemLibrary.h #include Widgets/SWindow.h EWindowMode UWindowControlBPLibrary::CachedWindowMode EWindowMode::Windowed; TSharedPtrSWindow UWindowControlBPLibrary::GetGameWindow() { if (!GEngine || !GEngine-GameViewport) { return nullptr; } // 优先用 GameViewport 的窗口而不是 GetActiveTopLevelWindow // 因为后者可能返回 Tooltip 之类的临时顶层窗口 return GEngine-GameViewport-GetWindow(); }这里我特意没用FSlateApplication::Get().GetActiveTopLevelWindow()虽然网上很多示例用它。原因是这个函数返回的是当前最活跃的顶层窗口鼠标悬停在工具提示上的瞬间它可能返回的是 Tooltip 窗口拿去做最小化就完全没反应。GEngine-GameViewport-GetWindow()指向明确稳定得多。3.2 最小化与还原为什么要先记住上一个模式最小化的实现逻辑不复杂但顺序必须对。bool UWindowControlBPLibrary::MinimizeGameWindow() { #if WITH_EDITOR if (GIsEditor) { UE_LOG(LogTemp, Warning, TEXT([WindowControl] PIE 环境请改用 Standalone 模式测试)); return false; } #endif TSharedPtrSWindow Window GetGameWindow(); if (!Window.IsValid()) { return false; } UGameUserSettings* Settings GEngine ? GEngine-GetGameUserSettings() : nullptr; if (!Settings) { return false; } // 记录当前模式还原时要用 CachedWindowMode Settings-GetFullscreenMode(); // 全屏类模式下窗口铺满屏幕最小化语义不成立先降级到窗口化 if (CachedWindowMode ! EWindowMode::Windowed) { Settings-SetFullscreenMode(EWindowMode::Windowed); Settings-ApplyResolutionSettings(false); } Window-Minimize(); return true; }有个细节很多人不知道ApplyResolutionSettings(false)里的那个false参数是bCheckForCommandLineOverrides。传false表示忽略命令行里的-ResX1280 -ResY720这类覆盖参数直接用你在代码里设的值。开发期调试分辨率时把它设成true反而方便打包时必须改回false否则玩家在启动器里设的参数会被游戏覆盖。还原函数要做两件事把窗口从最小化或最大化状态拉回来以及把全屏模式恢复回去。bool UWindowControlBPLibrary::RestoreGameWindow() { TSharedPtrSWindow Window GetGameWindow(); if (!Window.IsValid()) { return false; } // Restore 会同时处理从最小化还原和从最大化还原两种情况 Window-Restore(); UGameUserSettings* Settings GEngine ? GEngine-GetGameUserSettings() : nullptr; if (Settings Settings-GetFullscreenMode() ! CachedWindowMode) { Settings-SetFullscreenMode(CachedWindowMode); Settings-ApplyResolutionSettings(false); } // 还原后把窗口拉到最前避免被其他程序压住 Window-BringToFront(true); return true; }Window-Restore()这个方法名字起得很贴切它不区分你是从最小化还是从最大化状态来的统一恢复到上一次的正常窗口状态。这一点特别省事你不用自己维护一个状态机。至于还原的两种语义实际用起来是这样区分的任务栏上点图标还原走的是系统消息引擎内部会自己调Restore()你什么都不用做游戏里做一个还原按钮就是显式调上面这个函数。我建议在 UI 上只做一个最大化/还原的切换按钮最小化交给标题栏那个独立的横线按钮这样交互逻辑最符合玩家习惯。3.3 最大化独占全屏、无边框全屏和窗口化最大化的区别最大化这个词在 UE5 里其实对应三种完全不同的表现如果策划没说清楚做出来的东西很可能不是他想要的。第一种是真正的独占全屏Fullscreen切换时会重建交换链可能黑屏一两秒而且 AltTab 切出去再回来会有明显延迟。它的优势是性能最好帧率最稳适合对延迟敏感的游戏。第二种是无边框全屏WindowedFullscreen视觉上和全屏一模一样但底层是个没有边框的窗口切换几乎无感AltTab 也很流畅。这是目前绝大多数 PC 游戏的默认选择我个人也推荐优先用它。第三种是窗口化最大化也就是让窗口占满屏幕的工作区——工作区这个词很关键它指的是扣掉任务栏之后的那块区域。这种情况需要你手动算出尺寸因为SWindow::Maximize()的行为是交给系统处理的。bool UWindowControlBPLibrary::MaximizeGameWindow() { TSharedPtrSWindow Window GetGameWindow(); if (!Window.IsValid()) { return false; } // 已经最大化时再点一次就还原这样一个按钮就能做切换 if (Window-IsWindowMaximized()) { Window-Restore(); return true; } Window-Maximize(); return true; }注意Maximize()只对带系统边框的窗口化模式有效在无边框全屏下调用它不会有任何视觉变化。如果你要做窗口化最大化但不盖住任务栏的效果得自己取工作区尺寸然后手动画窗口。// 取扣掉任务栏之后的可用区域 FDisplayMetrics Metrics; FDisplayMetrics::RebuildDisplayMetrics(Metrics); const FSlateRect WorkArea Metrics.PrimaryDisplayWorkAreaRect; const float Width WorkArea.Right - WorkArea.Left; const float Height WorkArea.Bottom - WorkArea.Top; // 先切窗口化再按工作区尺寸重设分辨率 UGameUserSettings* Settings GEngine-GetGameUserSettings(); Settings-SetFullscreenMode(EWindowMode::Windowed); Settings-SetScreenResolution(FIntPoint(FMath::RoundToInt(Width), FMath::RoundToInt(Height))); Settings-ApplyResolutionSettings(false);一个实操心得切换分辨率这个动作一定要加互斥保护。玩家手速快的时候会连点好几次最大化按钮每次点击都触发一次交换链重建在某些显卡驱动上直接给你卡死或者花屏。我的做法是加一个bool bIsSwitching成员变量进入函数先判断、置位用FTimerHandle延迟半秒复位这半秒内所有窗口切换请求全部忽略。3.4 关闭正常退出、拦截关闭按钮与确认弹窗关闭这件事在 UE5 里有三个层次分清楚之后就不会乱。最表层是游戏内的退出按钮直接调UKismetSystemLibrary::QuitGame就行。这个节点蓝图里本来就有不用自己封装但它有个坑如果不传有效的 World 上下文在 PIE 下会报空指针。我封装一版更稳的。void UWindowControlBPLibrary::CloseGameWindow(bool bIgnorePlatformRestrictions) { if (!GEngine) { return; } // 遍历世界上下文优先找 Game 类型的世界 UWorld* TargetWorld nullptr; for (const FWorldContext Ctx : GEngine-GetWorldContexts()) { if (Ctx.WorldType EWorldType::Game || Ctx.WorldType EWorldType::PIE) { TargetWorld Ctx.World(); break; } } if (!TargetWorld) { // 拿不到世界上下文时退回更底层的退出请求 FPlatformMisc::RequestExit(bIgnorePlatformRestrictions); return; } UKismetSystemLibrary::QuitGame( TargetWorld, nullptr, EQuitPreference::Quit, bIgnorePlatformRestrictions); }第二个层次是拦截系统的关闭按钮也就是玩家点右上角那个叉或者按 AltF4。这个默认行为是直接退出如果你有是否保存进度的确认框就必须拦下来。UE5 里有两个切入点我建议都试一下因为不同版本表现有差异。第一个是 Slate 层面的退出请求处理器。// 建议在 GameInstance::Init 里注册 FSlateApplication::Get().SetExitRequestedHandler(FSimpleDelegate::CreateLambda([this]() { // 这里不要直接退出先弹确认框玩家确认后再调 CloseGameWindow ShowQuitConfirmDialog(); }));第二个是窗口层面的销毁拦截粒度更细针对的是单个窗口的关闭请求。TSharedPtrSWindow Window GEngine-GameViewport-GetWindow(); if (Window.IsValid()) { Window-SetRequestDestroyWindowOverride( FOnWindowRequestDestroy::CreateLambda([](const TSharedRefSWindow InWindow) { // 什么都不做就等于拒绝关闭改为弹窗询问 ShowQuitConfirmDialog(); })); }注意SetExitRequestedHandler在不同小版本上语义略有差别有的版本是退出已被请求允许你清理有的版本是退出被请求你可以阻止。上线前务必在你锁定的那个引擎小版本上实测一遍 AltF4别等到发行才发现确认框没弹出来。第三个层次是退出前的数据保护。不管玩家从哪条路退出你都需要一个统一的收尾点把存档写盘。我一般会同时挂两个地方重写UGameInstance::OnGameInstanceShutdown以及给FCoreDelegates::OnPreExit加一个委托。前者在正常的引擎关闭流程里会走到后者能覆盖一些更暴力的退出路径。// GameInstance 子类的 Init 里 FCoreDelegates::OnPreExit.AddUObject(this, UMyGameInstance::HandlePreExit); void UMyGameInstance::HandlePreExit() { // 这里只做同步的、快速的落盘操作别做任何耗时逻辑 SavePlayerProgressImmediate(); }这里必须强调一句退出流程里不要做任何异步操作也不要弹需要等待的 UI。操作系统给你的时间通常只有一两秒超时之后进程会被强杀异步任务根本跑不完。真正需要长时间保存的进度应该在游戏过程中定期存退出时只做最后一次增量写入。4. UMG 侧对接自绘标题栏与按钮事件的正确接法4.1 按钮点击事件的绑定与输入模式设置C 库写好了接下来是在 UMG 里把它接起来。这部分看着简单但有几个细节不做对按钮点了没反应。先做一个WBP_WindowTitleBar控件横向排布三个按钮分别对应最小化、最大化、关闭。每个按钮的OnClicked事件里直接调我们刚才暴露的节点。因为是用UBlueprintFunctionLibrary暴露的节点会出现在WindowControl分类下面搜索Minimize就能找到。第一个坑是输入模式。如果玩家的鼠标指针看不见按钮就点不了。要在游戏开始或者窗口初始化的时候设置。APlayerController* PC GetWorld()-GetFirstPlayerController(); if (PC) { PC-bShowMouseCursor true; FInputModeGameAndUI InputMode; InputMode.SetLockMouseToViewportBehavior(EMouseLockMode::DoNotLock); InputMode.SetHideCursorDuringCapture(false); PC-SetInputMode(InputMode); }EMouseLockMode::DoNotLock这个设置很关键。默认的鼠标锁定行为会把光标限制在视口内部在无边框窗口拖动的时候光标会被卡住拖动体验非常糟糕。第二个坑是按钮抢焦点。当你点击一个 UMG 按钮后这个按钮会保留键盘焦点之后按 AltF4 或者 Esc 这类快捷键会被按钮吞掉表现得像快捷键失灵了。解决办法是把标题栏上所有按钮的Is Focusable属性取消勾选让它们不参与焦点系统。第三个坑是鼠标捕获模式。如果你的项目用了 Enhanced InputDefaultViewportMouseCaptureMode默认是CapturePermanently会导致鼠标一直被抓着标题栏按钮的悬停高亮表现异常。建议在DefaultInput.ini里改掉。[/Script/Engine.InputSettings] DefaultViewportMouseCaptureModeNoCapture DefaultViewportMouseLockModeDoNotLock改完之后记得测试一下游戏内的视角旋转是否还正常有些第三人称项目依赖鼠标捕获来实现无限旋转改成NoCapture之后鼠标会跑出窗口需要改成按住右键才旋转的交互方式。4.2 无边框窗口拖动、双击标题栏切换最大化既然标题栏是自己画的那拖动窗口也得自己实现。这部分是纯 UMG Slate 的活儿思路是鼠标按下时记录光标和窗口左上角的偏移量鼠标移动时用当前光标位置减去偏移量得到新的窗口位置。先在WBP_WindowTitleBar里加一个背景Border或者SizeBox把它的Visibility设成Visible注意不能是SelfHitTestInvisible那样接收不到鼠标事件然后把拖动逻辑写在这个控件的 C 基类里。FReply UTitleBarWidget::NativeOnMouseButtonDown(const FGeometry InGeometry, const FPointerEvent InMouseEvent) { if (InMouseEvent.GetEffectingButton() EKeys::LeftMouseButton) { TSharedPtrSWindow Window GEngine-GameViewport ? GEngine-GameViewport-GetWindow() : nullptr; if (Window.IsValid()) { bDragging true; // 记录鼠标相对窗口左上角的偏移拖动过程中这个值保持不变 DragOffset InMouseEvent.GetScreenSpacePosition() - Window-GetPositionInScreen(); return FReply::Handled().CaptureMouse(TakeWidget()); } } return FReply::Unhandled(); } FReply UTitleBarWidget::NativeOnMouseMove(const FGeometry InGeometry, const FPointerEvent InMouseEvent) { if (bDragging) { TSharedPtrSWindow Window GEngine-GameViewport ? GEngine-GameViewport-GetWindow() : nullptr; if (Window.IsValid()) { Window-MoveWindowTo(InMouseEvent.GetScreenSpacePosition() - DragOffset); } return FReply::Handled(); } return FReply::Unhandled(); } FReply UTitleBarWidget::NativeOnMouseButtonUp(const FGeometry InGeometry, const FPointerEvent InMouseEvent) { if (bDragging InMouseEvent.GetEffectingButton() EKeys::LeftMouseButton) { bDragging false; return FReply::Handled().ReleaseMouseCapture(); } return FReply::Unhandled(); }提示如果拖动时发现窗口位置和鼠标有稳定偏移而且偏移量跟你系统的显示缩放比例差不多比如 150% 缩放下偏了 1.5 倍那就是 DPI 坐标空间没换算。用FSlateApplication::Get().GetApplicationScale()把坐标除或乘一下就能对上。双击标题栏切换最大化是 PC 玩家的肌肉记忆不做的话会有人来提 bug。实现上重写NativeOnMouseButtonDoubleClick里面调一下我们封装好的最大化函数。FReply UTitleBarWidget::NativeOnMouseButtonDoubleClick(const FGeometry InGeometry, const FPointerEvent InMouseEvent) { if (InMouseEvent.GetEffectingButton() EKeys::LeftMouseButton) { UWindowControlBPLibrary::MaximizeGameWindow(); return FReply::Handled(); } return FReply::Unhandled(); }有个细节要提醒双击事件的判定需要两次单击落在同一个控件上而且中间不能有别的控件抢走事件。如果你发现双击没反应先检查标题栏那个 Border 的Visibility是不是被设成了HitTestInvisible这是最常见的原因。另外建议在拖动开始的时候把窗口的最大化状态先解除。因为最大化状态下窗口尺寸是固定的拖动会表现得很奇怪。我的习惯是在NativeOnMouseButtonDown里先判断IsWindowMaximized()如果是就调Restore()然后把窗口位置对齐到光标下方这样拖动手感和系统原生标题栏一致。5. 打包后才会冒出来的坑与排查表5.1 任务栏遮挡、DPI 错位、多屏越界开发期一切正常打包给测试一跑问题就来了。这里挑三个我遇到过的、最典型的问题展开说。第一个是最大化之后任务栏被盖住了。这个现象的本质是你用的其实是WindowedFullscreen模式它会把整个屏幕包括任务栏区域都占掉。有些玩家能接受有些玩家会抱怨切不出去。如果你想要的是最大化但保留任务栏那就必须走前面讲的第三种方案——切Windowed模式然后用PrimaryDisplayWorkAreaRect算出可用区域手动设定尺寸。代价是窗口顶部会有一条系统标题栏你就不能用纯无边框的自绘 UI 了这是一个需要和美术、策划一起权衡的取舍。第二个是 DPI 错位。Windows 的显示缩放从 100% 到 250% 都有玩家在用缩放比例一变Slate 的逻辑像素和实际物理像素就不再是 1:1。具体表现是无边框窗口的标题栏看起来只有 30 像素高实际点击区域却偏了或者自定义光标和真实热区对不上。解决办法是在所有涉及屏幕坐标的计算里统一走 Slate 的坐标转换 API不要自己拿物理像素去算。// 物理像素转 Slate 逻辑像素 const float Scale FSlateApplication::Get().GetApplicationScale(); FVector2D LogicalPos PhysicalPos / Scale;第三个是多显示器越界。玩家可能把游戏装上之后换了显示器或者把一个显示器拔了这时候 ini 里存的WindowPosX/Y落在一块不存在的屏幕上窗口启动后直接看不见。必须在游戏启动、窗口初始化完成之后做一次位置校正。void UWindowControlBPLibrary::ClampWindowToDisplay() { TSharedPtrSWindow Window GetGameWindow(); if (!Window.IsValid()) { return; } FDisplayMetrics Metrics; FDisplayMetrics::RebuildDisplayMetrics(Metrics); const FSlateRect WorkArea Metrics.PrimaryDisplayWorkAreaRect; FVector2D Pos Window-GetPositionInScreen(); // 至少保证窗口有四分之一在屏幕内玩家才能拖回来 const float MinVisibleX 200.f; const float MinVisibleY 60.f; Pos.X FMath::Clamp(Pos.X, WorkArea.Left, FMath::Max(WorkArea.Left, WorkArea.Right - MinVisibleX)); Pos.Y FMath::Clamp(Pos.Y, WorkArea.Top, FMath::Max(WorkArea.Top, WorkArea.Bottom - MinVisibleY)); Window-MoveWindowTo(Pos); }FMath::Max那层嵌套不是为了好看是为了防止极端情况——比如工作区宽度小于 200 像素某些特殊分辨率的平板模式Clamp的 Min 大于 Max 会触发断言加上保护之后最坏情况也只是窗口贴边。5.2 常见问题速查表下面这张表是我自己整理的排查清单遇到问题先在表里对一遍能省掉一大半翻代码的时间。现象大概率原因处理方式蓝图里搜不到最小化节点UMG 和 GameUserSettings 都没暴露窗口句柄自己封装 BlueprintFunctionLibrary或直接写 CPIE 里点最小化把编辑器收起来了PIE 的 GameViewport 与编辑器共用顶层窗口用 Standalone 模式测试代码里加GIsEditor判断最大化后任务栏被遮挡实际用的是 WindowedFullscreen 而非窗口化最大化接受无边框全屏或改用工作区尺寸手动布局双击标题栏没反应控件 Visibility 设成了 SelfHitTestInvisible改为 Visible并确保没有其他控件拦截事件拖动窗口位置有固定偏移DPI 缩放没有换算坐标空间用GetApplicationScale()做一次换算AltF4 没走确认框直接退了没有拦截退出请求注册SetExitRequestedHandler或窗口销毁拦截切换分辨率黑屏一两秒交换链重建属正常现象加过渡遮罩加互斥锁防止连点打包后窗口跑到屏幕外换显示器或系统分辨率变化导致坐标失效启动时用DisplayMetrics的工作区做 Clamp还原后分辨率不对只调了 Restore没恢复全屏模式缓存原模式并回写 GameUserSettings点了按钮之后快捷键失灵按钮抢走了键盘焦点关闭按钮的Is Focusable属性移动端调用直接崩移动平台不存在 SWindow 这类顶层窗口用PLATFORM_WINDOWS等宏把代码隔离开关于最后一条补充一句如果你在做一个多平台项目窗口控制相关的代码一定要用平台宏包起来。我一般会在函数入口加一道判断非桌面平台直接返回false让调用方自己去处理这个平台上没有这个功能的情况而不是让游戏崩掉。6. 几个我踩过的坑和后续可以扩展的方向6.1 踩坑记录第一个坑是用了GetActiveTopLevelWindow导致偶发失灵。前面提过这个函数会返回当前最活跃的顶层窗口鼠标划过 Tooltip 的瞬间拿到的是 Tooltip。这个 bug 非常隐蔽因为它是偶发的我当初花了很久才想到打日志把窗口名字打出来看。改成GEngine-GameViewport-GetWindow()之后就彻底稳定了。第二个坑是ApplyResolutionSettings和ApplySettings到底调哪个。这两个函数很容易混。简单区分ApplyResolutionSettings只管分辨率相关的设置用在切换窗口模式和分辨率的时候ApplySettings管的是全部设置包括画面质量、垂直同步、帧率上限这些通常在设置菜单点应用的时候调一次。我早期图省事所有地方都调ApplySettings结果改个分辨率把玩家的画质设置也一起重置了被测试提了个 P2 级别的 bug。第三个坑是最小化之后再还原画面卡住不动。这个现象的原因是窗口被最小化时Slate 会暂停渲染循环有些依赖 Tick 的逻辑被冻住了。一般情况下引擎会处理好恢复但如果你自己写了特殊的渲染逻辑或者用了某些第三方插件可能会卡住。我的处理办法是在还原之后手动触发一次FSlateApplication::Get().InvalidateAllWidgets(false)强制重绘一遍实测有效。第四个坑是关闭确认框弹出后玩家点取消窗口状态错乱。原因是拦截了关闭请求之后窗口可能已经被系统标记成了即将销毁这时候你再操作它会出问题。正确的做法是在拦截回调里只做弹窗这一件事玩家点确认真要退出时再走一次正常的CloseGameWindow不要试图去撤销系统的关闭动作。6.2 可以继续扩展的方向窗口控制做完之后还有几个方向值得往下走我自己也在陆续补。一是把窗口设置和存档打通。玩家换电脑之后打开游戏希望窗口位置、分辨率、全屏模式都保持上次的样子。UGameUserSettings本身会把这些写进 ini但自定义的部分——比如你自绘标题栏的透明度、是否记住了自定义窗口大小——得自己用SaveGame存。我的做法是继承UGameUserSettings加字段重写ApplySettings和LoadSettings这样能跟引擎的设置系统完全融合。二是做一套分辨率下拉列表。UGameUserSettings::GetSupportedFullscreenResolutions和GetConvenientWindowedResolutions能直接拿到平台支持的分辨率数组但注意返回的列表可能包含当前显示器不支持的值上架前最好自己过滤一遍或者在切换后检测一下实际分辨率对不对不对就提示玩家。三是处理窗口失去焦点的表现。很多游戏会在玩家切到别的窗口时自动降低帧率甚至暂停游戏实现上监听FSlateApplication::Get().OnApplicationActivationStateChanged()配合SetMaxFPS使用。这个细节对笔记本玩家的电池续航帮助很大做出来之后成就感还挺强。最后再分享一个小技巧调试窗口相关的功能时我会在屏幕上挂一个临时的调试文本实时显示当前窗口模式、是否最小化、是否最大化、窗口坐标这四个值。因为窗口状态变化很快靠打断点根本抓不住有个实时显示能省掉大量猜测。等调试完把那个调试控件删掉就行代码结构上留一个#if !UE_BUILD_SHIPPING就够了。