UE5.5 中三种子关卡加载方式各有明确的适用场景和权衡取舍，以下是详细对比：
一、 加载方式
1. 关卡流送（Level Streaming）
原理
通过UGameplayStatics::LoadStreamLevel或蓝图节点，在运行时手动加载/卸载子关卡。子关卡在编辑器中预先配置位置、旋转等属性，由持久关卡（Persistent Level）统一管理。
优点
- 手动控制精确：开发者可以完全控制何时加载/卸载哪个关卡，适合剧情驱动的线性流程。
- 同步实例化透明：引擎内部会根据流送策略自动分帧激活 Actor（如按 LOD 优先级、空间分区等），避免单帧卡顿。
- 适合非欧几里得空间：如需要一扇门连接两个物理上不可能相邻的位置，手动流送可以灵活控制。
缺点
- 运行时配置受限：加载后无法动态修改子关卡的位置、旋转等预先配置的属性。
- 手动管理开销大：需要开发者自己规划加载时机和区域边界，不适合超大规模开放世界。
- 多人协作冲突：子关卡文件容易产生版本控制冲突。
适用场景
- 线性关卡或章节式游戏（如《生化危机》式房间切换）
- 需要精确控制加载时机的剧情演出
- 非欧几里得空间效果（无限走廊、传送门等）
2. 世界分区（World Partition）
原理
UE5 引入的自动空间分区系统，将整个世界划分为均匀的 Cell 网格，基于玩家位置（流送源）自动加载/卸载 Cell。配合 HLOD（分层细节级别）和 Nanite 使用，实现"所见即所得"的流送。
优点
- 全自动流送：无需手动管理，系统根据玩家位置和 Loading Range 自动处理加载/卸载。
- 内存占用极低：在 256km² 的地图中，仅需加载玩家周边约 1km² 的资源。
- 支持超大规模世界：配合 64 位大世界坐标（LWC），可构建远超 UE4 尺寸限制的地图。
- 多人协作友好：采用一 Actor 一文件（OFPA），减少版本冲突。
- HLOD 集成：远处物体卸载时自动生成代理网格，避免"凭空消失"的视觉断层。
缺点
- 灵活性受限：自动流送基于距离，难以实现复杂的自定义流送逻辑（如剧情触发加载）。
- 小地图性价比低：对于 1.5km² 以下的中小型地图，手动关卡流送可能更简单稳定。
- 跨轴 Actor 问题：覆盖到坐标轴上的 Actor 可能永远处于加载状态（5.3 后已有解决方案）。
- 稳定性顾虑：部分开发者反馈在中小型项目中仍不够稳定，功能迭代较快。
适用场景
- 开放世界游戏（如《塞尔达》《艾尔登法环》式大地图）
- 超大规模场景（>4km²）
- 需要多人协作开发的大型项目
- Nanite + HLOD 全栈优化的项目
3. 关卡实例（Level Instances）
原理
将一组 Actor 打包为可复用的子关卡，支持在场景中多次实例化。运行时分为嵌入模式（默认，推荐）和关卡流送模式两种。
优点
- 高效复用：同一子关卡可在场景中生成多个实例，修改原始关卡后所有实例自动更新。
- 上下文编辑：支持在当前场景中直接编辑实例内容，无需反复进出子关卡。
- 变换信息支持：通过特殊 Actor 实现实例的位置、旋转、缩放变换。
- 支持嵌套：可以在子关卡中再嵌套其他子关卡，构建复杂层级。
缺点
- 嵌入模式限制：使用 OFPA 的实例在运行时会"溶解"到世界分区网格中，非 OFPA Actor（如 AWorldSettings）会丢失。
- 流送模式性能差：非 OFPA 实例使用传统关卡流送，运行时开销高，不适合大量实例。
- 依赖世界分区：离开世界分区系统后，关卡实例不会自动实现流送管理。
适用场景
- 重复性 POI（兴趣点）：如森林中的多个相似树屋、迷宫中的相同房间。
- 模块化建筑：可复用的房屋、营地、商店等预制件。
- 动态修改需求：需要在运行时动态改变实例属性（如光照、颜色）而不影响原始关卡。
- 打包型关卡蓝图：用于静态建筑和密集视觉设置的渲染优化（如《遗迹峡谷》的 Mega Assemblies）。
总结对比表
| 维度 | 关卡流送 | 世界分区 | 关卡实例 |
|---|---|---|---|
| 控制方式 | 手动（代码/蓝图） | 全自动（基于距离） | 半自动（嵌入或流送模式） |
| 适用规模 | 中小型、线性 | 大型、超大型开放世界 | 模块化、重复性内容 |
| 内存管理 | 开发者手动控制 | 引擎自动优化（极低内存） | 依赖底层模式 |
| 灵活性 | 高（精确控制时机） | 低（按距离自动） | 中（复用+变换） |
| 协作开发 | 易冲突（子关卡文件） | 友好（OFPA） | 友好（复用原始关卡） |
| 典型场景 | 线性剧情、传送门 | 开放世界、大地图 | 重复建筑、POI 预制件 |
实际项目中的组合使用
在大型开放世界项目中，通常三者结合：
- 世界分区作为底层架构，管理整个大地图的自动流送。
- 关卡实例用于生成重复的 POI（如村庄、营地），以嵌入模式融入世界分区网格。
- 关卡流送用于处理特殊剧情区域或需要精确控制的加载时机（如地下城入口、剧情演出房间）。
二、关卡实例的两种加载方式
1.附加在关卡实例 Actor 里（Embedded / 嵌入模式）
- 这是默认且推荐的方式
- 在关卡中放置
Level InstanceActor，选择要引用的子关卡 - 运行时这些 Actor直接实例化到当前关卡中，成为持久关卡的一部分
- 使用 OFPA（One File Per Actor）时，实例会"溶解"到世界分区的网格中，参与自动流送管理
- 没有额外的流送开销，性能最优
2.蓝图加载Load Level Instance（Level Streaming / 流送模式）
- 通过蓝图节点
Load Level Instance或Unload Level Instance动态加载 - 运行时以传统关卡流送的方式加载子关卡
- 会创建独立的关卡上下文，有额外的流送管理开销
- 适合需要动态加载/卸载的场景，但不适合大量实例
关键区别
| 维度 | 嵌入模式（Level Instance Actor） | 流送模式（Load Level Instance） |
|---|---|---|
| 加载时机 | 关卡加载时自动实例化 | 运行时手动/动态加载 |
| 运行时开销 | 低（直接实例化） | 较高（传统流送系统） |
| OFPA 支持 | 支持，融入世界分区 | 不支持，独立关卡上下文 |
| 动态控制 | 不支持运行时切换 | 支持运行时加载/卸载 |
| 适用场景 | 静态复用内容（建筑、POI） | 动态内容（按需加载的房间） |
| 推荐程度 | ⭐ 默认推荐 | 特定场景使用 |
简单记忆
嵌入模式= 把子关卡"粘贴"进当前关卡，成为一体
流送模式= 把子关卡当作独立关卡动态加载/卸载
什么时候用哪种？
嵌入模式：绝大多数场景。比如你在开放世界里放 20 个相似的村庄，每个都是同一个子关卡的实例，直接拖进场景就行，世界分区会自动管理它们的流送。
流送模式：需要运行时动态控制的场景。比如玩家进入某个特定区域后才加载一个地下城，或者需要根据游戏状态切换不同的房间布局。
注意：
嵌入模式使用的LevelInstance Actor不可动态生成并加载关卡，能在编辑器内使用但不能在打包后使用，这在引擎层面并没有被完整支持。
