企业官网建设流程全解析

1. 项目概述：从“层”的混乱到清晰

如果你是从UE4或者更早版本迁移到UE5的开发者，或者刚开始接触UE5的大型世界构建，那么“层”（Layers）这个概念可能会让你感到困惑。在UE4时代，我们习惯在关卡编辑器的“图层”面板里管理物件，把一堆静态网格体、灯光、体积框选一下，丢进一个叫“建筑_外墙”或者“植被_树木”的图层里，方便批量隐藏和显示。这个系统直观、简单，但它的局限性在开放世界或大型关卡中暴露无遗：它本质上是编辑器内的一个“标签”系统，与世界的流送、运行时状态管理几乎无关。

进入UE5的World Partition时代，Epic引入了Data Layers（数据层）。第一次在“窗口”->“世界分区”->“数据层大纲视图”里看到它时，你可能会想：“这不就是换了个名字的图层吗？” 我最初也是这么认为的，直到在实际项目中踩了无数个坑，才彻底明白这是两个设计哲学、底层架构和应用场景完全不同的系统。把Data Layers当成高级版的普通Layers来用，是项目后期出现各种诡异流送问题、性能瓶颈和协作冲突的根源。

这篇指南的目的，就是帮你彻底厘清这两个“层”的核心区别。这不是一篇简单的功能对比列表，而是结合我多个UE5项目（从中小型场景到超大型开放世界）的实战经验，深入剖析Data Layers的设计意图、工作原理以及那些官方文档可能不会明说的“坑点”。无论你是技术美术、关卡设计师还是主程，理解这五个关键区别，都能让你在World Partition框架下更高效、更稳定地构建和管理你的世界。

2. 核心概念拆解：两种“层”的本质差异

在深入对比之前，我们必须先建立正确的认知模型。普通关卡Layers和Data Layers，虽然中文都叫“层”，但英文原词和其代表的抽象层级就暗示了不同。

2.1 普通关卡Layers：编辑器的“可视化标签簿”

普通关卡Layers，在UE4/UE5中通常被称为“Layers”或“Actor Layers”。它的核心定位是编辑器内的组织与筛选工具。你可以把它想象成Photoshop里的图层，或者一个复杂的Excel表格里的筛选标签。

• 数据存储：Layer信息直接存储在关卡文件（.umap）中。当你创建一个名为“Lighting_Interior”的层并把一个点光源放进去时，这个关联关系被记录在关卡文件里。
• 运行时状态：无。这是最根本的一点。关卡Layers在游戏打包后、运行时完全不存在。你无法在游戏运行过程中通过蓝图或C++代码去查询、激活或禁用某个关卡Layer。它的全部作用就是在编辑阶段帮你管理视口里Actor的可见性。
• 操作对象：以Actor为基本单位。你只能将整个Actor放入一个或多个Layer。
• 协作影响：由于信息存在关卡文件里，当多个开发者需要编辑同一个关卡的不同部分（比如A编辑建筑，B编辑植被）时，如果他们都修改了Layer的成员列表，就极易在版本控制（如Perforce, Git）上产生冲突，需要频繁解决合并问题。

简单说，普通Layers是一个“临时”的、为编辑便利性服务的本地化工具。

2.2 Data Layers：世界的“动态加载与状态管理模块”

Data Layers是World Partition系统的一个核心子系统。它的设计初衷是为了解决大型、动态、可流送世界的资产管理问题。你可以把它理解为一套精密的“开关控制面板”，每个开关（Data Layer）控制着一组世界元素的加载、卸载、可见与不可见。

• 数据存储：这是第一个巨大区别。Data Layers的信息是资产化和实例化的。
  1. Data Layer Asset（数据层资产）：这是一个独立的引擎资产（UDataLayerAsset），保存在内容浏览器里（如/Game/DataLayers/DL_Weather_Rain）。它定义了层的“类型”（Editor或Runtime）和基础属性。它是跨关卡、跨世界可复用的模板。
  2. Data Layer Instance（数据层实例）：这是在特定世界（关卡）中，Data Layer Asset的一个具体实例。它包含了该层在这个世界中的具体状态（初始是否加载、是否可见等）。这个实例信息存储在世界专属的WorldDataLayers文件中，而不是主关卡文件。
• 运行时状态：核心特性。Data Layers（特指Runtime类型）拥有完整的运行时状态机：Unloaded（未加载）、Loaded（已加载但不可见）、Activated（已激活，即加载且可见）。你可以在蓝图中用Set Data Layer Instance Runtime State节点，或在C++中通过UDataLayerSubsystem来动态切换这些状态，从而实现游戏内事件触发的场景变化（如昼夜切换、区域解锁、剧情触发后的环境改变）。
• 操作对象：与World Partition深度绑定，管理的是世界分区单元（Grid Cell）内Actor的流送。将一个Actor指定给一个Data Layer，意味着这个Actor的加载/卸载将受到该Data Layer状态的控制。
• 协作影响：得益于World Partition的“一Actor一文件”原则，当设计师A将某个岩石Actor加入到DL_Ruins_Destroyed层，而设计师B将某个树木Actor加入到DL_Foliage_Forest层时，他们修改的是两个不同的Actor文件，几乎不会产生冲突。WorldDataLayers文件虽然可能被多人修改，但其结构更稳定，冲突概率远低于整个关卡文件。

本质上，Data Layers是World Partition实现动态世界流送和状态管理的核心逻辑单元，而不仅仅是视觉整理工具。

3. 五个关键区别深度剖析与避坑实践

理解了本质差异，我们来看五个最具体、也最容易让人栽跟头的区别。每一个区别都对应着实际开发中的一个决策点或一个潜在的“坑”。

3.1 区别一：运行时存在性——静态标签 vs 动态开关

这是最根本、最重要的区别，决定了你能用这个“层”来做什么。

普通Layers：仅存于编辑时它在打包后就被“剥离”了。你不能写这样的蓝图逻辑：“当玩家进入区域时，隐藏‘建筑_临时’层里的所有物体。” 因为运行时引擎根本不知道“建筑_临时”这个层是什么。你只能通过其他方式，比如手动将那些物体分组到一个Actor数组里，或者给它们添加标签（Tags），然后通过标签来查找和控制。这增加了设计的复杂性和维护成本。

Data Layers：完整的运行时生命周期Runtime类型的Data Layers在游戏中是真实存在的对象。你可以在任何游戏逻辑中访问它们。一个经典的用法是“世界状态切换”：

1. 场景：一个村庄，有“平常日”和“节日”两种状态。
2. 实现：创建两个Runtime Data Layer Assets:DL_Village_Normal和DL_Village_Festival。
3. 布置：将平常日的物件（普通摊位、安静NPC）指定给DL_Village_Normal；将节日特有物件（彩旗、特殊装饰、庆祝NPC）指定给DL_Village_Festival。在WorldDataLayers中，将DL_Village_Festival的初始状态设为Unloaded。
4. 逻辑：当游戏内时间到达节日，或者玩家触发某个任务时，在蓝图或C++中执行：

   // C++ 示例片段 if (UDataLayerSubsystem* DLS = GetWorld()->GetSubsystem<UDataLayerSubsystem>()) { DLS->SetDataLayerInstanceRuntimeState(DL_Village_Normal_Asset, EDataLayerRuntimeState::Loaded); // 保持加载但隐藏 DLS->SetDataLayerInstanceRuntimeState(DL_Village_Festival_Asset, EDataLayerRuntimeState::Activated); // 加载并显示 }

5. 效果：村庄瞬间从平常状态切换到节日状态，所有节日装饰和NPC自动流送进来并显示，而平常日的部分物件可以被隐藏或移除。这一切都是动态的、基于流送的，无需硬加载整个关卡。

避坑指南1：切勿混用设计意图最大的坑就是试图用普通Layers去做运行时管理。我曾见过有团队为了方便，把需要动态显示/隐藏的物体都塞进普通Layer，然后在运行时尝试用遍历所有Actor并检查其Layer名称的方式来模拟控制，结果导致巨大的性能开销和难以维护的代码。设计初期就要明确：需要运行时动态控制的物件，必须使用Data Layers（Runtime）来管理。

3.2 区别二：数据存储与协作——中心化冲突 vs 分布式解耦

这个区别直接影响团队协作的效率和版本控制的复杂度。

普通Layers：中心化的关卡文件所有Layer的定义和Actor归属关系都挤在同一个.umap文件里。想象一下，一个拥有成千上万个Actor的大型关卡，两个关卡设计师同时在工作：

• 设计师A：在区域东边，把一堆岩石加到了“地形_岩石”层。
• 设计师B：在区域西边，把几棵树加到了“植被_树木”层。 当他们提交时，两人都修改了同一个关卡文件的Layer列表部分，版本控制系统会立即报告冲突。解决这种冲突非常麻烦，需要手动合并文本，极易出错。

Data Layers：分布式的资产与实例Data Layers系统巧妙地将数据拆分：

1. Data Layer Asset：作为独立资产，创建后很少改动。即使重命名，也只是一个标签变化，不影响引用它的实例和Actor。
2. Actor归属信息：存储在Actor各自的文件里（One File Per Actor）。设计师A修改岩石Actor的Data Layers属性，只保存岩石文件；设计师B修改树木Actor的属性，只保存树木文件。这两个操作完全独立，不会冲突。
3. WorldDataLayers文件：它主要存储Data Layer Instance的列表和它们的初始状态。虽然多人可能同时修改（比如都新增了Instance），但冲突概率和解决难度远低于整个庞大的关卡文件。

避坑指南2：善用Data Layer Asset进行标准化为了最大化协作优势，建议项目早期就由技术负责人或主美创建一套标准的Data Layer Asset库。例如：/Game/DataLayers/Environment/DL_Env_Rock/Game/DataLayers/Gameplay/DL_GP_Spawner_Enemy/Game/DataLayers/Lighting/DL_Light_Dynamic所有团队成员都从内容浏览器中拖拽这些预设资产到数据层大纲视图来创建实例，而不是每次都“创建新数据层”（这会创建无资产的实例，难以统一管理）。这确保了命名、类型（Editor/Runtime）和调试颜色的统一，极大提升了项目的可维护性。

3.3 区别三：管理粒度与范围——整体Actor vs 流送单元绑定

这个区别关乎你如何组织你的世界内容。

普通Layers：基于Actor的简单分组它只关心“这个Actor在哪个层”。一个复杂的建筑Actor，可能包含上百个静态网格体组件，但它作为一个整体，要么在全在层A，要么全不在。你无法用Layer控制建筑内部某个房间的桌椅是否流送。

Data Layers：与World Partition网格深度集成Data Layers的管理逻辑是：“在这个Data Layer激活时，所有被分配到这个层的、且位于玩家流送范围内的Actor，都应该被加载。” 这里的关键是流送范围。

• 场景：一个超大的开放世界地图，被World Partition自动划分为许多网格单元（Grid Cell）。
• 操作：你将一片森林区域的所有树木Actor指定给DL_Foliage_DenseForest。
• 运行时：当玩家远离这片森林时，承载森林的网格单元处于非流送状态，那么无论DL_Foliage_DenseForest是Activated还是Loaded，这些树木都不会被加载到内存中。Data Layer的状态是Actor加载的必要条件，而非充分条件。Actor首先必须在其所属的网格单元进入流送范围后，才会进一步根据其Data Layer的状态决定是否加载和显示。

避坑指南3：理解“加载”的优先级这是一个非常常见的困惑点。当你发现一个Data Layer被设置为Activated，但其中的Actor却没显示时，请按以下顺序排查：

1. 流送优先级：该Actor所在的World Partition网格单元是否已被加载？可以在编辑器运行时使用showflag.worldpartitiongrid命令查看网格加载情况。
2. Data Layer状态：在“数据层大纲视图”或通过wp.DumpDatalayers控制台命令，确认该Data Layer实例的运行时状态确实是Activated。
3. Actor归属：在Actor的细节面板“数据层”分段，确认它确实被正确分配给了目标Data Layer Asset的实例。 很多情况下，问题出在第一步——你以为Data Layer是万能的开关，其实它只是流送系统之上的一个精细过滤器。

3.4 区别四：类型与用途——单一功能 vs 双重职责

普通Layers只有一种用途。Data Layers则根据类型分化出两种不同的职责。

普通Layers：唯一的用途就是编辑器内隐藏/显示功能单一，所有Layer都一样。

Data Layers：Editor型与Runtime型的明确分工

• Editor Data Layers：纯粹用于编辑器内组织内容。它的行为和普通Layers最像，用于在编辑时隐藏/显示特定类型的Actor（如所有碰撞体积、所有调试点、所有临时占位模型）。它在打包后会被完全剔除，没有任何运行时开销。你可以放心创建很多Editor层来保持场景整洁。
• Runtime Data Layers：用于游戏运行时的动态内容管理。如前所述，它拥有完整的状态机，是游戏逻辑的一部分。每个Runtime Data Layer都会在运行时占用一点内存来管理其状态，并且其状态变化会触发流送系统的加载/卸载操作。

避坑指南4：严格区分Editor与Runtime我强烈建议建立命名规范来区分两者，例如：

• Editor层前缀：EDL_(如EDL_Collision,EDL_Debug,EDL_Temp)
• Runtime层前缀：DL_(如DL_Weather_Rain,DL_Quest_Act1,DL_Time_Night)千万不要把本该是Editor层的内容放到Runtime层。比如，你把所有碰撞体积放到一个Runtime层，然后游戏逻辑中永远不去动它。这会导致：

1. 无谓的运行时内存占用。
2. 增加了数据层子系统状态管理的复杂度。
3. 其他程序员或设计师可能会误以为这个层是可以通过游戏逻辑控制的，造成混淆。 正确的做法是：所有不需要在运行时通过代码动态控制显示/隐藏的、仅用于编辑整理的物件，一律使用Editor Data Layers。

3.5 区别五：工作流程与转换——平滑迁移 vs 断代革新

从旧项目迁移或混合使用两种系统时，这里有无数的坑。

普通Layers：旧世界的遗产在非World Partition的普通关卡中，它是标准配置。但在World Partition关卡中，虽然你依然能看到“图层”面板，但它与Data Layers系统是并行且不互通的两套系统。一个Actor可以同时属于一个普通Layer和一个Data Layer，两者互不影响。

Data Layers：新世界的标准它是World Partition的“一等公民”。Epic提供了从旧版Layer系统迁移到Data Layers的工具（DataLayerToAsset命令），但迁移并非一键无忧。

避坑指南5：迁移与混合使用的注意事项情况一：将旧关卡转换为World Partition使用“工具”->“转换关卡”后，旧的普通Layers不会自动变成Data Layers。它们依然作为普通Layers存在。你需要手动决定哪些Layer需要转换成Runtime Data Layers（用于动态控制），哪些可以废弃或转为Editor Data Layers。情况二：在World Partition关卡中同时使用两者这是允许的，但必须头脑清晰：

• 普通Layers：只用于极其临时的、个人的编辑分组。例如，你今天想同时调整分散在地图各处的10盏特定路灯，可以把它们临时加到一个叫“Temp_Lights”的普通Layer里，调完就清空这个Layer。因为它不保存到Actor文件，也不会影响协作。
• Data Layers：用于所有正式的、需要持久化、可能需要协作或运行时控制的内容组织。绝对要避免：设计了一套基于Data Layers的完整内容管理流程，同时又让团队成员习惯性地使用普通Layers去组织正式资产，导致管理混乱。团队需要统一规范，明确“在World Partition项目中，正式的内容组织请使用数据层大纲视图（Data Layers Outliner）”。

4. 实战配置与高级技巧

理解了区别，我们来看看如何正确设置和使用Data Layers。

4.1 创建与管理Data Layers的最佳实践

1. 规划先行：在项目预生产阶段，由技术美术或技术策划牵头，规划出项目所需的Data Layer清单。按功能域分类，例如：

   • Environment(环境):DL_Env_River,DL_Env_Cliff
   • Gameplay(玩法):DL_GP_Quest_Item_Act1,DL_GP_Spawner_Wildlife
   • Visuals(视觉):DL_VFX_Ambient_Dust,DL_Light_DayCycle
   • Audio(音频):DL_Audio_Zone_Forest(可通过Data Layer控制不同区域环境音的加载)

2. 资产创建：在内容浏览器的特定目录（如/Game/DataLayers）下，右键创建这些Data Layer Asset。创建时即明确选择Editor或Runtime类型，并设置好调试颜色（Debug Color），便于在视口中区分。

3. 实例化与初始化：在世界中打开数据层大纲视图，将规划好的Data Layer Asset拖入，创建其实例。在实例的细节面板中，仔细设置其初始状态：

   • 初始已加载：该层中的Actor在所属网格流送后，是否默认加载到内存？
   • 初始可见：该层中的Actor加载后是否默认可见？（仅对Editor层有效）
   • 初始运行时状态：对于Runtime层，其游戏开始时的状态（Unloaded,Loaded,Activated）。这是你设计关卡初始状态的关键。

4.2 在蓝图与C++中动态控制Data Layers

动态控制是Data Layers的灵魂。这里分享一些蓝图和C++中的实用技巧。

蓝图控制示例：简单的区域触发器常见需求：玩家进入一个区域，加载并显示该区域的特定装饰层。

1. 创建一个Box Collision体积，在其细节面板的“事件”中，添加On Actor Begin Overlap和On Actor End Overlap事件。
2. 在Begin Overlap事件后，连接Get Data Layer Subsystem节点，然后连接Set Data Layer Instance Runtime State节点。在Data Layer引脚上选择或创建变量引用你的目标Data Layer Asset（如DL_Decoration_CaveEntrance），将State设置为Activated。
3. 在End Overlap事件后，可以设置状态为Loaded（保持加载但隐藏）或Unloaded（完全卸载），取决于你的性能与设计需求（如果玩家频繁进出，可能保持Loaded更合适）。

C++控制示例：基于游戏状态的全局切换对于更复杂的状态管理，如全局的“白天/黑夜”切换，在C++中处理更清晰。

// 头文件声明 UCLASS() class YOURGAME_API ATimeOfDayManager : public AActor { GENERATED_BODY() public: // 切换至白天状态 UFUNCTION(BlueprintCallable, Category = "TimeOfDay") void SwitchToDayState(); // 切换至黑夜状态 UFUNCTION(BlueprintCallable, Category = "TimeOfDay") void SwitchToNightState(); private: // 通过资产引用指向你的Data Layer Asset UPROPERTY(EditAnywhere, Category = "DataLayers") TObjectPtr<const UDataLayerAsset> DayLayerAsset; UPROPERTY(EditAnywhere, Category = "DataLayers") TObjectPtr<const UDataLayerAsset> NightLayerAsset; // 或者通过名称动态查找（灵活性更高） UPROPERTY(EditAnywhere, Category = "DataLayers|Advanced") FName DayLayerName = TEXT("DL_Time_Day"); UPROPERTY(EditAnywhere, Category = "DataLayers|Advanced") FName NightLayerName = TEXT("DL_Time_Night"); }; // 源文件实现 void ATimeOfDayManager::SwitchToDayState() { if (UDataLayerSubsystem* DLS = GetWorld()->GetSubsystem<UDataLayerSubsystem>()) { // 方法1：使用资产引用（推荐，类型安全） if (DayLayerAsset && NightLayerAsset) { DLS->SetDataLayerInstanceRuntimeState(NightLayerAsset, EDataLayerRuntimeState::Loaded); // 隐藏黑夜层 DLS->SetDataLayerInstanceRuntimeState(DayLayerAsset, EDataLayerRuntimeState::Activated); // 显示白天层 } // 方法2：使用名称动态查找（处理未在属性中预设的情况） else if (!DayLayerName.IsNone() && !NightLayerName.IsNone()) { if (const UDataLayerAsset* FoundDayLayer = DLS->GetDataLayerAssetFromName(DayLayerName)) { DLS->SetDataLayerInstanceRuntimeState(FoundDayLayer, EDataLayerRuntimeState::Activated); } // ... 类似处理黑夜层 } } }

技巧：在C++中，建议使用TObjectPtr<const UDataLayerAsset>进行资产引用，这样在编辑器中可以直接拖拽赋值，既安全又方便。同时，可以暴露一个FName参数作为备用，方便动态查找或通过数据表配置。

4.3 性能考量与优化策略

不当使用Data Layers会成为性能杀手。

1. 避免“上帝层”：不要创建一个名为DL_Main的层，然后把60%的Actor都丢进去。这违背了Data Layers用于精细化管理流送的初衷。当一个庞大的层状态改变时，会触发巨量Actor的同步加载/卸载，导致帧率卡顿。原则是：按功能、按区域、按使用频率进行细粒度划分。

2. 理解状态转换开销：Unloaded->Loaded的开销最大，涉及磁盘I/O和内存分配。Loaded<->Activated主要是可见性切换和可能的一些逻辑初始化（如BeginPlay），开销相对较小。因此，对于玩家可能频繁切换的区域（如进出房屋），考虑让相关层保持Loaded状态，只切换Activated状态。

3. 流送优先级冲突：Data Layer的加载请求会与World Partition基于距离的流送请求共同作用。如果大量Data Layer同时请求加载远处网格的Actor，可能会阻塞玩家近处更紧急的流送请求。可以使用wp.Runtime.SetDataLayerRuntimeState命令在开发时模拟测试，观察流送性能。

4. 使用调试命令：UE5提供了强大的调试命令来监控Data Layers：

   • wp.DumpDatalayers：在输出日志中打印所有数据层及其当前状态。
   • wp.Runtime.ToggleDrawDataLayers：在游戏视口中叠加显示数据层边界和状态，非常直观。
   • wp.Runtime.DebugFilterByDatalayer [LayerName]：在2D流送调试视图中，只显示指定数据层相关的网格单元。

5. 常见问题排查与解决方案实录

在实际项目中，你会遇到各种各样奇怪的问题。这里记录了几个最典型的案例和解决方法。

5.1 问题：Data Layer状态已激活，但Actor不显示

• 排查步骤：
  1. 确认流送：按下~键打开控制台，输入showflag.worldpartitiongrid 1`，查看该Actor所在的网格是否已变成高亮（表示已加载）。如果没加载，问题出在World Partition流送距离或设置上。
  2. 确认归属：在编辑器中选择该Actor，查看其细节面板“数据层”分段，确认它被分配给了正确的Data Layer Asset的实例。有时可能会误选到同名的不同Asset。
  3. 检查实例状态：在数据层大纲视图中，找到对应的Data Layer Instance，确认其“初始运行时状态”或当前运行时状态是否为Activated。注意，如果它是某个父层的子层，父层的状态会覆盖子层。
  4. 检查Actor自身：确保Actor本身的“隐藏”属性未被勾选，或者没有被其他逻辑（如蓝图）动态隐藏。

5.2 问题：在蓝图中无法找到或设置某个Data Layer

• 可能原因与解决：
  1. 类型错误：你尝试在蓝图中控制一个Editor类型的Data Layer。编辑器层无法在运行时被蓝图访问。确保你引用的是Runtime类型的Data Layer Asset。
  2. 引用丢失：在蓝图中通过“选择资产”引用的Data Layer Asset被移动或重命名。需要重新指定引用。
  3. 子系统获取时机：在游戏刚开始（如Event BeginPlay）时获取Data Layer Subsystem，有时可能因为世界初始化顺序问题而失败。可以尝试在Event Tick后稍微延迟一帧再操作，或者将操作放在玩家控制器或游戏模式的BeginPlay中。

5.3 问题：从旧项目迁移后，Layer关联丢失或混乱

• 解决方案： 使用Epic提供的命令行工具进行迁移是最佳起点，但迁移后务必进行人工审计。
  1. 运行迁移命令：如文档所述，使用UnrealEditor.exe YourProject -run=DataLayerToAssetCommandlet YourMap -DestinationFolder=/Game/DataLayerConversion。
  2. 审计生成资产：检查在目标文件夹生成的Data Layer Assets。旧Layer的名称可能包含空格或特殊字符，迁移后可能不符合命名规范，需要手动重命名。
  3. 检查Actor分配：打开迁移后的地图，抽样检查一些重要Actor，看其Data Layers分配是否正确。特别是那些原来属于多个Layer的Actor，迁移后可能只保留了第一个关联。
  4. 区分Editor/Runtime：迁移工具通常将所有旧Layer转为Runtime类型。你需要手动判断哪些层其实只用于编辑（如Debug、Temp），并将其Asset类型改为Editor。

5.4 问题：多人协作时，Data Layer的修改导致频繁冲突

• 最佳实践：
  1. 固化Asset库：如前所述，建立项目级的标准Data Layer Asset库，并设置为只读或权限控制，避免团队成员随意创建不一致的Asset。
  2. 规范实例创建流程：规定在世界中创建Data Layer Instance时，必须从内容浏览器拖拽标准Asset，而不是在数据层大纲视图中右键“创建新数据层”（这会创建无资产的“未知”实例）。
  3. 细分WorldDataLayers文件（高级）：对于超大型项目，可以考虑通过引擎源码修改或插件，将WorldDataLayers数据按功能或区域拆分到多个文件中，减少单一文件的修改冲突概率。但这属于高级定制，需评估必要性。

5.5 问题：Data Layers与Level Instancing（关卡实例化）的配合问题

当使用关卡实例（Level Instancing）或打包型关卡蓝图（Packed Level Blueprint, PLB）时，Data Layers的行为需要特别注意。

• 继承规则：默认情况下，关卡实例内的Actor会继承其父实例Actor所拥有的Data Layers。这意味着，如果你将一个关卡实例Actor放入DL_Quest_Area1，那么该实例内部的所有Actor默认也属于DL_Quest_Area1。
• 额外指定：同时，关卡实例内的Actor还可以被指定额外的、独立于父实例的Data Layers。这提供了极大的灵活性。例如，一个“房屋”关卡实例被放在DL_Village_House层，但房屋内部的“宝藏”Actor可以被额外指定给DL_Quest_Treasure层，只有当任务触发时，宝藏才出现，而房子本身一直存在。
• 引用缺失：这是个大坑！如果关卡实例内部引用了一个Data Layer Asset，但这个Asset的实例在当前主世界中不存在，那么这个引用会被静默忽略。例如，你在一个可复用的“环境包”关卡实例里，将一些特效Actor指定给了DL_VFX_Wind。当你把这个实例放到主世界A时，如果主世界A没有创建DL_VFX_Wind的实例，那么这些特效Actor的Data Layer指定就会失效。解决方案是：要么在主世界创建所有可能用到的Data Layer实例；要么在关卡实例内部使用更通用的、在所有世界都会创建的Data Layer（如DL_Environment）；要么通过蓝图在运行时动态管理这些Actor的可见性，而不是依赖Data Layer。