虚幻引擎插件开发：从模块依赖到跨平台部署的5大核心技巧

1. 项目概述：为什么我们需要关注UE插件开发？

如果你是一名C++程序员，并且正在使用虚幻引擎（Unreal Engine， 简称UE）开发游戏，那么迟早有一天，你会遇到一个场景：引擎自带的功能不够用了。可能是需要一个特殊的网络同步方案，一个独特的材质编辑器节点，或者一个能批量处理资源的自动化工具。这时候，你面临两个选择：要么把代码硬塞进现有的游戏项目里，让项目结构变得臃肿不堪；要么，就是走一条更优雅、更专业的道路——开发一个独立的UE插件。

这个标题“从零搭建高性能游戏模块的5大核心技巧”，精准地戳中了所有中高级UE开发者的痛点。它不是一个泛泛而谈的教程，而是直指“高性能”和“核心技巧”，这意味着内容将超越基础的“如何创建一个插件按钮”，深入到架构设计、性能优化和工程化实践的层面。对于希望提升代码复用性、团队协作效率，乃至未来将自己的功能打包出售的开发者来说，掌握插件开发是必经之路。本文将围绕这五大核心技巧，结合我多年在AAA项目和独立项目中的插件开发经验，为你拆解从零开始构建一个健壮、高效、易于维护的UE插件所需的关键知识与实战细节。

2. 核心技巧一：精准规划模块依赖与构建配置

插件开发的第一步不是写代码，而是做好“蓝图”规划。一个混乱的依赖关系会让编译时间暴涨，并带来难以追踪的链接错误。UE的构建系统（Unreal Build Tool, UBT）基于模块（Module）运作，理解并驾驭它是高性能插件的基础。

2.1 理解Build.cs：依赖关系的指挥官

每个模块都有一个[ModuleName].Build.cs文件，它决定了这个模块的“社交关系”。这里面的核心是两个列表：PublicDependencyModuleNames和PrivateDependencyModuleNames。

公共依赖（PublicDependencyModuleNames）：当你的模块的头文件（.h）中使用了其他模块的类、结构体或函数时，你必须将该模块列为公共依赖。因为任何包含你头文件的第三方模块，也需要能访问到你所依赖的那些模块的头文件。例如，你的插件公开了一个UMyAwesomeComponent类，其头文件中包含了#include “GameFramework/Actor.h”，那么“GameplayAbilities”（如果用了AActor）就必须是公共依赖。

私有依赖（PrivateDependencyModuleNames）：当依赖仅存在于你的**.cpp文件**中时，应该将其列为私有依赖。这是最推荐的方式，因为它能最大限度地减少头文件暴露，缩短编译链。例如，你的插件内部实现用到了Json库来解析数据，但这个解析过程完全封装在.cpp里，对外不可见，那么“Json”模块就应该是私有依赖。

一个常见的误区是图省事，把所有依赖都扔进公共列表。这会导致“依赖传染”。假设插件A公共依赖了插件B，而你的游戏项目又依赖了插件A，那么即使你的游戏完全用不到插件B的功能，UBT也会强制编译并链接插件B，增加不必要的编译时间和最终包体大小。

实操心得：我习惯在编写类之前，先草拟Build.cs。列出这个模块需要哪些引擎模块（如Core,CoreUObject,Engine）、哪些其他插件模块。然后严格审视：这个头文件会被外部引用吗？如果答案是否定的，就坚决地把依赖移入私有列表。对于像Slate（UI框架）或RenderCore（渲染核心）这类大型模块，保持依赖的私有化对编译速度的提升尤为明显。

2.2 优化构建配置：为性能与分发铺路

Build.cs文件中的ReadOnlyTargetRules Target参数提供了丰富的配置选项，让你能针对不同目标（游戏、编辑器、客户端、服务器等）进行精细化控制。

// MyPlugin.Build.cs 示例片段 public class MyPlugin : ModuleRules { public MyPlugin(ReadOnlyTargetRules Target) : base(Target) { PCHUsage = ModuleRules.PCHUsageMode.UseExplicitOrSharedPCHs; // 使用共享PCH加速编译 bEnableExceptions = true; // 谨慎开启，仅在确实需要C++异常时启用 // 公共依赖：头文件中用到的 PublicDependencyModuleNames.AddRange(new string[] { “Core”, “CoreUObject”, “Engine”, “InputCore” // 假设我们公开的类需要处理输入 }); // 私有依赖：仅实现中用到的 PrivateDependencyModuleNames.AddRange(new string[] { “Slate”, “SlateCore”, “Json”, “HTTP” // 内部进行网络请求 }); // 条件依赖：仅在编辑器中需要的模块 if (Target.bBuildEditor) { PrivateDependencyModuleNames.Add(“UnrealEd”); PrivateDependencyModuleNames.Add(“EditorStyle”); } // 针对特定平台添加依赖或库 if (Target.Platform == UnrealTargetPlatform.Win64) { PublicAdditionalLibraries.Add(“ThirdParty/Win64/MySDK.lib”); } else if (Target.Platform == UnrealTargetPlatform.Android) { string PluginPath = Utils.MakePathRelativeTo(ModuleDirectory, Target.RelativeEnginePath); AdditionalPropertiesForReceipt.Add(“AndroidPlugin”, Path.Combine(PluginPath, “MyPlugin_APL.xml”)); } // 优化：强制包含（或排除）特定头文件，慎用！ // PublicIncludePaths.Add(...); // ShadowVariableWarningLevel = WarningLevel.Off; } }

关键配置解析：

• PCHUsage：设置为UseExplicitOrSharedPCHs是推荐做法。它会为你的模块生成预编译头文件，显著加速增量编译。确保你的Private目录下有一个[ModuleName].PrivatePCH.h文件，并在其中包含最常用、改动最少的头文件。
• bEnableExceptions：UE默认禁用C++异常以提升性能。除非你集成的第三方库强烈依赖异常，否则保持为false。错误处理应优先使用UE的check()、ensure()宏以及返回错误码的模式。
• 条件编译(Target.bBuildEditor)：这是分离运行时逻辑和编辑器逻辑的关键。编辑器专用的功能（如自定义细节面板、工具栏扩展）所依赖的模块（如UnrealEd,EditorStyle）必须放在条件块内。这能保证你的插件在打包后的游戏（非编辑器目标）中不会引入不必要的代码和依赖，对减小包体至关重要。
• 平台特定处理：集成第三方SDK时，经常需要链接不同的库文件。通过判断Target.Platform，你可以为不同平台指定不同的库文件路径或编译选项。对于Android，通常还需要配置额外的APL（Android Plugin Library）文件来声明JNI、权限等。

注意：修改Build.cs后，必须重新生成项目文件（右键点击.uproject文件选择“Generate Visual Studio project files”或运行引擎目录下的GenerateProjectFiles.bat），否则更改不会生效。

3. 核心技巧二：设计清晰高效的模块与类结构

模块的物理结构决定了代码的可见性和组织方式。UE强制（或强烈建议）的Public和Private文件夹规范，是管理复杂性的利器。

3.1 Public vs Private：设立明确的API边界

• Public/目录：存放对外公开的头文件（.h）。这里定义的类、结构体、枚举和函数，可以被其他模块访问。这是你插件的“门面”。设计时要极度谨慎，遵循“最小暴露原则”。一旦公开，再想修改或删除就会破坏向后兼容性。
• Private/目录：存放所有的**.cpp实现文件以及仅内部使用的头文件**。实现细节、辅助类、工具函数都应该藏在这里。即使是一个仅在Public中某个类内部使用的PImpl（指针指向实现）类，其定义也应放在Private中。

推荐的目录结构示例：

MyPlugin/ ├── Source/ │ ├── MyPlugin/ │ │ ├── Public/ │ │ │ ├── MyPlugin.h // 主模块头文件，包含最重要的类声明 │ │ │ ├── Components/ │ │ │ │ └── MyPluginComponent.h // 公开的游戏组件 │ │ │ ├── Interface/ │ │ │ │ └── IMyPluginInterface.h // 公开的接口 │ │ │ └── MyPluginLibrary.h // 公开的工具函数库 │ │ ├── Private/ │ │ │ ├── MyPlugin.cpp // 主模块实现 │ │ │ ├── MyPluginPrivatePCH.h // 预编译头文件 │ │ │ ├── Components/ │ │ │ │ └── MyPluginComponent.cpp │ │ │ ├── Internal/ │ │ │ │ └── InternalHelper.h // 内部使用的辅助类头文件 │ │ │ └── PCH.cpp // 预编译头源文件 │ │ └── MyPlugin.Build.cs │ └── MyPluginEditor/ // 编辑器模块（可选，独立模块） │ ├── Public/ │ │ └── ... │ ├── Private/ │ │ └── ... │ └── MyPluginEditor.Build.cs └── Resources/ // 图标、本地化文件等

为什么这样设计？

1. 编译防火墙：将实现细节隐藏在Private后，修改这些细节（例如，更改一个内部数据结构）只需要重新编译当前模块，而所有依赖此模块的其他模块都无需重新编译，因为它们的头文件依赖没有变化。
2. 清晰的契约：Public文件夹就是你的插件与外界签订的契约。开发者只需看这里的头文件，就能明白如何使用你的插件，而无需关心内部复杂的实现逻辑。
3. 工具支持：UE的“新建C++类”向导会自动将文件放入正确的Public/Private子目录，与你的类命名空间保持一致，保持了结构的整洁。

3.2 善用前向声明与PImpl模式

在Public头文件中，应极力避免#include其他模块的头文件，尤其是大型或复杂的头文件。这可以通过前向声明（Forward Declaration）来实现。

// MyPluginComponent.h (Public头文件) #pragma once #include “CoreMinimal.h” #include “Components/ActorComponent.h” // 不好的做法：#include “Engine/Texture2D.h” // 好的做法：前向声明 class UTexture2D; // 前向声明 #include “MyPluginComponent.generated.h” UCLASS(Blueprintable, ClassGroup=(Custom), meta=(BlueprintSpawnableComponent)) class MYPLUGIN_API UMyPluginComponent : public UActorComponent { GENERATED_BODY() public: // 使用指针或引用时，前向声明足够 UPROPERTY(EditAnywhere, BlueprintReadWrite, Category=”Texture”) TObjectPtr<UTexture2D> MyTexture; // 只需要前向声明 // 如果函数返回或参数是值类型，则需要完整定义，此时必须#include // FLinearColor是内置简单结构，通常已包含在CoreMinimal.h的传递链中 UFUNCTION(BlueprintCallable) FLinearColor GetPixelColor(FVector2D UV) const; };

对应的.cpp文件则需要包含完整的头文件：

// MyPluginComponent.cpp (Private实现文件) #include “MyPluginComponent.h” #include “Engine/Texture2D.h” // 在这里包含实现所需的头文件 #include “MyPlugin/Private/Internal/InternalHelper.h” // 包含内部头文件 // ... 实现代码

对于更复杂的场景，可以考虑PImpl（Pointer to Implementation）模式，将所有的私有成员变量和实现细节隐藏在一个指向内部类的指针之后。这能最大程度地减少公共头文件的变动，提供最佳的二进制兼容性。不过，在UE中需权衡其带来的间接访问开销。

实操心得：养成习惯，在Public头文件中写完类声明后，检查所有#include。问自己：这个类型是否只以指针或引用形式出现？如果是，尝试用前向声明替换#include。这能显著减少编译依赖，尤其是在大型团队协作中，一个核心头文件的微小改动可能触发数百个文件的重新编译。

4. 核心技巧三：实现高性能的运行时逻辑

插件不仅要在编辑器中好用，更要在运行时高效。游戏是实时应用，每一毫秒都至关重要。

4.1 内存管理：拥抱UE的智能指针系统

C++原生new/delete或malloc/free在UE插件中是危险的，因为它们绕过了引擎的内存管理器和垃圾回收器（GC），极易导致内存泄漏或悬挂指针。UE提供了自己的一套智能指针系统：

1. TSharedPtr/TSharedRef/TWeakPtr：用于管理非UObject对象。其行为类似于C++11的std::shared_ptr等，但与UE的线程模型和内存分配器集成得更好。适用于插件内部的数据管理、管理器类等。

   TSharedPtr<FMyInternalData> InternalData = MakeShared<FMyInternalData>(); TWeakPtr<FMyInternalData> WeakData = InternalData; // 打破循环引用

2. TUniquePtr：用于独占所有权的非UObject对象。轻量，无引用计数开销。

   TUniquePtr<FScopedCalculation> Calculator = MakeUnique<FScopedCalculation>();

3. UObject系统与UPROPERTY()：所有继承自UObject的类（你的AActor,UActorComponent,UDataAsset等）都由GC管理。确保所有指向其他UObject的指针属性都用UPROPERTY()宏标记，否则GC无法识别其引用关系，会导致对象被意外回收，引发崩溃。

   UPROPERTY(EditAnywhere, BlueprintReadWrite) AActor* TargetActor; // 正确：UPROPERTY标记，受GC保护 // UPROPERTY() // 错误：忘记标记！ UMyObject* MyObjectPtr; // 危险！可能被GC回收，变成野指针。

性能陷阱：避免在Tick（每帧执行）函数中频繁创建/销毁智能指针或UObject。对象的构造和析构，尤其是触发GC，是有成本的。对于需要频繁更新的数据，考虑使用对象池或复用机制。

4.2 多线程与异步任务

游戏逻辑通常在主线程（游戏线程）运行，但一些耗时操作（如文件I/O、网络请求、复杂计算）如果阻塞主线程，会导致游戏卡顿。UE提供了多种在插件中安全使用多线程的方式：

1. AsyncTask系统：最简单的方式，将任务抛到线程池中执行。

   Async(EAsyncExecution::ThreadPool, []() { // 在后台线程中执行耗时操作 FPlatformProcess::Sleep(2.0f); // 模拟耗时操作 FString Result = TEXT(“Done”); // 完成后，如果需要更新UI或游戏状态，必须回到游戏线程 AsyncTask(ENamedThreads::GameThread, [Result]() { // 现在在游戏线程中，可以安全地修改UObject或更新Slate UI UE_LOG(LogTemp, Log, TEXT(“Async task completed: %s”), *Result); }); });

2. FRunnable与FRunnableThread：需要更精细控制的生命周期和优先级的长期运行线程。

3. FAsyncTask/FGraphEvent：用于构建有依赖关系的任务图，适合并行计算。

关键注意事项：

• 线程安全：UE的大部分容器（如TArray,TMap）和UObject API都不是线程安全的。在后台线程中访问或修改它们必须加锁（如使用FCriticalSection或FScopeLock）。
• 游戏线程回调：任何需要修改UObject属性、调用蓝图函数、更新Slate UI的操作，都必须在游戏线程中执行。AsyncTask(ENamedThreads::GameThread, ...)是标准的“回主线程”方法。
• 资源释放：确保在线程结束时，所有对UObject或共享数据的引用都被正确释放或置空，防止内存泄漏。

4.3 数据驱动与配置化

高性能插件不应将逻辑硬编码。通过数据资产（UDataAsset）、数据表（UDataTable）或配置文件（.ini）来驱动行为，可以让策划或美术人员调整参数而无需重新编译代码，也便于做性能调优。

// 1. 创建数据资产类 UCLASS(BlueprintType) class MYPLUGIN_API UMyPluginConfig : public UDataAsset { GENERATED_BODY() public: UPROPERTY(EditAnywhere, BlueprintReadOnly, Category=”Performance”) int32 MaxConcurrentTasks = 4; UPROPERTY(EditAnywhere, BlueprintReadOnly, Category=”Gameplay”, meta=(ClampMin=”0.0", ClampMax=”1.0")) float EffectStrengthMultiplier = 1.0f; }; // 2. 在组件中引用并应用配置 UCLASS(ClassGroup=(Custom), meta=(BlueprintSpawnableComponent)) class MYPLUGIN_API UMyPluginRuntimeComponent : public UActorComponent { GENERATED_BODY() protected: UPROPERTY(EditAnywhere, Category=”Config”) TObjectPtr<UMyPluginConfig> PluginConfig; virtual void BeginPlay() override { Super::BeginPlay(); if (PluginConfig) { // 使用配置的值 CurrentStrength = BaseStrength * PluginConfig->EffectStrengthMultiplier; } } };

在编辑器中，你可以创建一个UMyPluginConfig资产，并分配给多个UMyPluginRuntimeComponent实例。调整资产中的EffectStrengthMultiplier，所有使用该资产的组件行为都会同步改变，无需修改代码。

5. 核心技巧四：打造用户友好的编辑器扩展

一个优秀的插件，其编辑器体验应与引擎原生功能无缝集成。这不仅能提升开发效率，也是插件专业度的体现。

5.1 自定义细节面板（Customization）

当你在插件中创建了新的UCLASS，并添加了UPROPERTY，它们默认会出现在细节面板的“杂项”类别下。通过自定义细节面板，你可以：

• 分组：将相关属性组织到折叠栏中。
• 重排：控制属性显示的顺序。
• 条件显示/隐藏：根据其他属性的值动态显示或隐藏某些属性。
• 自定义控件：为特定类型的属性提供更友好的编辑控件（如颜色选择器、曲线编辑器）。

实现步骤：

1. 创建一个继承自IDetailCustomization的类。
2. 重写CustomizeDetails方法，使用IDetailLayoutBuilder来编排属性。
3. 在模块启动时（StartupModule中）注册这个自定义类到对应的UClass。

// 在编辑器模块中 class FMyActorDetailsCustomization : public IDetailCustomization { public: static TSharedRef<IDetailCustomization> MakeInstance() { return MakeShareable(new FMyActorDetailsCustomization()); } virtual void CustomizeDetails(IDetailLayoutBuilder& DetailBuilder) override { // 隐藏默认分类 DetailBuilder.HideCategory(“Rendering”); // 创建一个自定义分类 IDetailCategoryBuilder& MyCategory = DetailBuilder.EditCategory(“MyPlugin”, FText::GetEmpty(), ECategoryPriority::Important); // 将特定属性添加到这个分类，并设置其显示名称、工具提示等 MyCategory.AddProperty(GET_MEMBER_NAME_CHECKED(AMyPluginActor, MySpecialProperty)); } }; // 在模块的StartupModule中注册 FPropertyEditorModule& PropertyModule = FModuleManager::LoadModuleChecked<FPropertyEditorModule>(“PropertyEditor”); PropertyModule.RegisterCustomClassLayout( AMyPluginActor::StaticClass()->GetFName(), FOnGetDetailCustomizationInstance::CreateStatic(&FMyActorDetailsCustomization::MakeInstance) );

别忘了在模块的ShutdownModule中取消注册，防止内存泄漏。

5.2 工具栏与菜单扩展

将插件的常用功能暴露在编辑器工具栏或菜单中，可以极大提升工作流效率。这通常通过FExtender和FToolBarBuilder/FMenuBuilder来实现。

// 扩展主工具栏 TSharedPtr<FExtender> ToolbarExtender = MakeShareable(new FExtender); ToolbarExtender->AddToolBarExtension( “Settings”, // 扩展点的位置，如”Settings”后 EExtensionHook::After, nullptr, // 或某个命令列表 FToolBarExtensionDelegate::CreateRaw(this, &FMyPluginEditorModule::AddToolbarButton) ); FLevelEditorModule& LevelEditorModule = FModuleManager::LoadModuleChecked<FLevelEditorModule>(“LevelEditor”); LevelEditorModule.GetToolBarExtensibilityManager()->AddExtender(ToolbarExtender); // 定义按钮 void FMyPluginEditorModule::AddToolbarButton(FToolBarBuilder& Builder) { Builder.AddToolBarButton( FUIAction( FExecuteAction::CreateRaw(this, &FMyPluginEditorModule::OnToolbarButtonClicked), FCanExecuteAction() ), NAME_None, FText::FromString(“My Plugin”), FText::FromString(“Execute my plugin function”), FSlateIcon(FMyPluginStyle::GetStyleSetName(), “MyPlugin.ToolbarIcon”) ); }

5.3 自定义资源类型与编辑器

如果你的插件引入了新的资源格式（如自定义的数据资产、配置文件），为其创建自定义的编辑器（UAssetEditor）可以提供最佳的编辑体验。这涉及创建新的Factory（用于创建资源）、AssetTypeActions（用于在内容浏览器中定义右键菜单和缩略图）以及一个SCompoundWidget或更复杂的编辑器窗口。

这是一个相对高级的主题，但它能让你的插件看起来和用起来都像是引擎原生的一部分。Epic官方的EditorScriptingUtilities插件、Niagara编辑器等都是很好的学习范例。

实操心得：编辑器扩展代码应放在独立的编辑器模块中（例如MyPluginEditor模块），并在其Build.cs中条件依赖UnrealEd、Slate、SlateCore、EditorStyle等模块。通过.uplugin文件控制该模块仅在编辑器中加载，确保运行时包体不受影响。

6. 核心技巧五：确保跨平台兼容性与高效打包分发

插件最终要交付给用户使用，可能运行在PC、主机、移动设备甚至云端。跨平台兼容性和打包的便捷性是专业插件的最后一道关卡。

6.1 处理平台差异

代码中避免直接使用平台特定的API或路径。UE提供了丰富的跨平台抽象：

• 路径：使用FPaths类，如FPaths::ProjectPluginsDir()、FPaths::ConvertRelativePathToFull()。永远不要硬编码“C:\”或“/Users/”。
• 文件I/O：使用FPlatformFileManager和IFileHandle，或者更高层的FFileHelper。
• 系统信息：使用FPlatformMisc、FPlatformProcess、FPlatformTime。
• 图形API：如果涉及RHI（渲染硬件接口），使用RHICmdList等抽象接口，而不是直接的OpenGL或DirectX调用。

对于必须使用平台特定代码的情况（如调用某个只有Windows才有的系统函数），使用预处理器宏：

#if PLATFORM_WINDOWS #include “Windows/AllowWindowsPlatformTypes.h” // Windows-specific code #include “Windows/HideWindowsPlatformTypes.h” #elif PLATFORM_MAC // macOS-specific code #elif PLATFORM_LINUX // Linux-specific code #endif

6.2 配置.uplugin文件

.uplugin文件是插件的“身份证”和“说明书”，它定义了插件的基本信息、模块、依赖和加载规则。

{ “FileVersion”: 3, “Version”: 1, “VersionName”: “1.0”, “FriendlyName”: “My Awesome Plugin”, “Description”: “A high-performance plugin for Unreal Engine.”, “Category”: “Programming”, // 或 “Rendering”, “Blueprint” “CreatedBy”: “Your Name/Studio”, “CreatedByURL”: “https://yourwebsite.com”, “DocsURL”: “https://yourdocs.com”, “MarketplaceURL”: “”, “SupportURL”: “”, “EnabledByDefault”: true, “CanContainContent”: true, // 插件是否可以包含内容（资产） “IsBetaVersion”: false, “Installed”: false, “Modules”: [ { “Name”: “MyPlugin”, “Type”: “Runtime”, // 运行时加载 “LoadingPhase”: “Default”, “WhitelistPlatforms”: [“Win64”, “Mac”, “Linux”] // 可运行平台 }, { “Name”: “MyPluginEditor”, “Type”: “Editor”, // 仅编辑器加载 “LoadingPhase”: “PostEngineInit” // 在引擎初始化后加载 } ], “Plugins”: [ // 插件依赖 { “Name”: “ExamplePlugin”, “Enabled”: true } ] }

关键字段：

• LoadingPhase：对于需要在游戏启动早期初始化的插件（如修改引擎核心行为），可以设置为PreDefault或PostConfigInit。大多数插件用Default即可。编辑器专用模块常用PostEngineInit。
• WhitelistPlatforms/BlacklistPlatforms：精确控制插件在哪些平台生效。例如，一个依赖特定显卡功能的渲染插件，可以只白名单Win64和特定主机平台。
• 依赖管理：在Plugins数组中声明依赖的其他插件，确保加载顺序正确。如果依赖的插件未启用，你的插件将无法加载。

6.3 测试、打包与分发

1. 单元测试：为插件的核心逻辑编写单元测试（使用UE的Automation框架）。这能保证代码修改不会破坏现有功能，尤其是在团队协作中。
2. 烹饪（Cook）测试：在打包前，务必对包含你插件的项目进行完整烹饪和打包测试。许多编辑器下运行正常的问题（如资源引用错误、序列化问题）会在打包后暴露。
3. 创建安装包：分发插件时，最简单的格式是直接将插件文件夹（包含Source、Resources、Content、.uplugin文件）打包成ZIP。用户解压到项目的Plugins目录下即可。
4. 文档与示例：提供清晰的README.md，说明功能、安装方法、API和简单的使用示例。在插件内包含一个/Content/Examples地图或蓝图，是最直观的教学方式。

踩坑记录：我曾遇到一个插件在编辑器下完美运行，但打包后崩溃的问题。排查后发现，是在一个#if WITH_EDITOR的代码块外，不小心使用了编辑器模块才有的函数。UBT在打包非编辑器目标时不会链接那些模块，导致函数未定义。教训是：严格区分编辑器与运行时代码，并使用#if WITH_EDITOR宏进行条件编译，同时在Build.cs中做好条件依赖。

7. 常见问题与排查技巧实录

即使遵循了所有最佳实践，开发过程中仍会遇到各种问题。以下是一些典型问题及其排查思路：

最后的建议：开发UE插件是一个系统工程，涉及C++功底、对引擎架构的理解、工具链的熟悉以及良好的软件设计习惯。从一个小功能开始，逐步迭代，并积极利用引擎源码（Epic提供了大部分引擎代码）作为最权威的参考资料。多阅读引擎中其他插件的实现（如Paper2D、AIModule），你会发现很多巧妙的模式和最佳实践。当你成功发布第一个被他人使用的插件时，那种成就感是无与伦比的。