一、实际边界：当前模型一次只合并公共层与一个关卡

现有实践以稳定 LevelId 管理多个关卡，Catalog 区分主关卡与活动关卡。保存时把完整编辑树拆成公共片段和当前关卡片段；打开或切换时再把公共层与目标关卡合并。切换过程会卸载当前关卡拥有的根，再挂载目标关卡。

这套模型很适合大厅、小游戏、章节或独立玩法场景：任一时刻只有一个私有关卡参与编辑，公共服务和框架对象持续存在。它避免每个关卡复制公共对象，也给保存、恢复和跨版本校验建立了清晰单元。

二、为什么不能直接叫“大世界方案”

大世界中，玩家站在分区边界时需要多个 Cell 同时驻留；物理、导航、AI、复制相关性和 HLOD 还可能使用不同半径。此时不再存在唯一 ActiveLevelId，而是一个持续变化的 Residency Set。

若沿用“先卸载 A、再挂载 B、最后提交活动关卡”，会产生明显问题：

边界移动频繁触发保存与结构事务；
A/B 无法重叠驻留，出现视觉或碰撞空洞；
跨分区约束、导航路径和网络对象没有稳定宿主；
公共层膨胀为“所有跨区对象的收容所”，最终失去分区价值。

三、目标架构：空间分区是独立的运行时投影

作者数据仍可按语义关卡组织，但发布编译阶段应生成空间 Cell：

AuthoringProject
  -> semantic levels and stable objects
  -> partition compiler
  -> CellManifest { bounds, dependencies, hashes, cost, object ranges }
  -> runtime residency controller

运行时维护多集合，而不是单活动关卡：

Wanted      空间和玩法当前需要
Preparing   后台解码、资产与碰撞准备
Resident    已提交，可查询/可见/可模拟
Retiring    超出范围但仍处于滞回或被引用

Cell 的进入采用 Prepare/Commit，退出使用引用计数、滞回和预算回收。跨 Cell 引用只能是迟绑定稳定身份；强生命周期对象应提升到独立常驻层，不能隐式阻止整个 Cell 卸载。UE 的 World Partition、Level Streaming 或自研数据层都只是承载手段，关键仍是上述身份、依赖和提交契约。

四、取舍与验证

分区编译增加了边界切割、跨 Cell 引用、HLOD、导航与离线验证成本，不应为了“小地图很多”提前引入。只有业务需要连续空间、并发驻留和预算化流式时才值得升级。

验收要沿边界往返移动，制造异步乱序、内存压力和资产失败，验证无空洞、无重复对象、无跨 Cell 悬空约束，并分别统计 Prepare、Commit、驻留和回收成本。结论是：多关卡是正确的互斥场景管理；大世界需要另一个以空间需求集合为核心的运行时。