UE5.8 Primary Asset Labels 与 Chunk 划分：让 Patch 和 DLC 各回各家

老周记得那个周三凌晨特别清楚。运营刚发完一个 120MB 的紧急补丁，玩家后台评论区却炸了锅：更新包显示 1.8GB。

他拖着小林和阿杰进会议室，把构建日志往桌上一拍。三份 Pak 文件摊在屏幕上：pakchunk0-Windows.pak 占了 2.1GB，pakchunk1-Windows.pak 只多了 80MB，可玩家客户端偏偏把两个都重新下一遍。原因很简单：上一周把一批武器皮肤从 Chunk 0 挪到了 Chunk 1，Cooker 认为依赖关系变了，整块 Pak 的哈希签名全部失效。平台分发系统不认内容，只认签名，于是 1.8GB 里有 1.7GB 都是白烧的流量。

那晚老周在白板上写了八个字：标签不乱，Chunk 不炸。Primary Asset Labels 就是解决这个问题的把手。

1. Primary Asset Labels 到底是什么

Primary Asset Labels 是 UE5.8 里一类特殊的资产，继承自 UPrimaryAssetLabel。它的作用很单纯：给一堆资产打上一个统一的 Chunk 归属和优先级。你可以把它理解成分拣标签。仓库里的货物五花八门，标签告诉打包机这一箱该走哪条传送带。

在老周的项目里，武器、角色皮肤、地图、过场动画、活动资源全混在一起。Asset Manager 扫描的时候能看到所有 Primary Asset，但默认情况下它们都归到 Chunk 0。Chunk 0 是基础包，玩家第一次安装就要全部下载。把不该进基础包的内容塞进去，安装包会膨胀；把该进基础包的挪出去，运行时又会缺资源。

Primary Asset Label 的字段很少，但每个都直接决定打包行为：

• Label: FName — 标签名字，Asset Manager 按这个识别规则。
• Chunk ID: int32 — 目标 Pak Chunk 编号，0 通常保留给基础包。
• Priority: int32 — 同一个资产被多个 Label 命中时的优先级，数值越大越优先。
• Apply Recursively: bool — 是否把 Chunk 分配递归到依赖的 Secondary Asset。
• Explicit Assets — 显式指定归入本 Label 的资产列表。
• Rules: FPrimaryAssetRules — 覆盖加载和 Cook 规则。

老周最喜欢的一点是 Label 可以叠加。一把武器可以同时挂在 Label_Weapons_Core 和 Label_SeasonWinter2026 上。前者决定这把武器属于哪个 Chunk，后者决定它在冬季活动里的加载策略。两个 Label 各司其职，不互相打架。

flowchart TD
    subgraph labels ["Primary Asset Labels"]
        lbl_weapon["Label: Weapons"]
        lbl_skin["Label: Skins"]
        lbl_map["Label: Maps"]
        lbl_event["Label: Events"]
    end
    subgraph assets ["Primary Assets"]
        w["Rifle_Laser"]
        s["Hero_Winter"]
        m["Map_Desert"]
        e["Event_Xmas"]
    end
    subgraph chunks ["Pak Chunks"]
        c0["Chunk 0 Base"]
        c1["Chunk 1 Weapons"]
        c2["Chunk 2 Skins"]
        c3["Chunk 3 Events"]
    end
    lbl_weapon --> w
    lbl_skin --> s
    lbl_map --> m
    lbl_event --> e
    w --> c1
    s --> c2
    m --> c0
    e --> c3

上图把关系拉得很清楚。Label 是桥梁，左边连着资产，右边连着 Chunk。没有这座桥，Asset Manager 只能把资产 blindly 塞进 Chunk 0。

2. Pak Chunk 分组策略

Chunk 是 Cook 和 Pak 阶段的物理分组。每个 Chunk 对应一个或多个 .pak 文件，发布平台按这些文件做差异更新。分组策略直接决定 Patch 大小、DLC 拆分粒度和运行时加载效率。

老周团队最初的策略是按资产类型分：所有武器进 Chunk 1，所有皮肤进 Chunk 2，所有地图进 Chunk 3。这种分法在美术部门很受欢迎，因为目录结构清晰。可上线后他们发现，Patch 包体还是很大。问题出在共享依赖上。

假设十把武器共用一套基础材质和贴图。如果按武器类型把每把武器塞进不同 Chunk，这套共享材质就会被复制到每个 Chunk 里。Pak 内部虽然会做去重，但 Patch 时任意一把武器改动都会让这套材质所在的 Pak 重新签名，导致其他武器 Chunk 也被误判为变化。

更好的做法是把共享依赖单独拎出来。老周后来画了这样一张表：

Chunk	内容	更新频率	加载时机
0	引擎基础、启动关卡、共享材质、核心代码	极低	启动即加载
10	共享武器框架、基础动画、通用音效	低	进入主菜单后
20	普通武器与皮肤	中	装备或局内
30	地图与关卡资源	中	匹配到具体地图
40	活动与赛季资源	高	活动开启后
50	DLC 扩展包	按需	玩家购买后

这个表里没有大道理，只有实践中的取舍。Chunk 0 尽量稳，Chunk 40 和 50 允许频繁变动，Chunk 10 专门收留共享依赖。

分组时还要考虑粒度。Chunk 太少，Patch 一改动就牵动全身；Chunk 太多，Pak 文件碎成渣，IO 头和 Seek 时间会吃掉加载性能。老周的经验是：单 Chunk 大小控制在 50MB 到 500MB 之间比较舒服。小于 50MB，文件头开销占比太高；大于 500MB，移动端的下载恢复和校验成本会明显上升。

单 Chunk 的下载时间可以写成：

$T_{dl} = \frac{S_{chunk}}{B_{net}} + \frac{S_{chunk}}{B_{disk}} + T_{hash}$

其中 $S_{chunk}$ 是 Chunk 大小，$B_{net}$ 是玩家网络带宽，$B_{disk}$ 是本地写入带宽，$T_{hash}$ 是校验时间。Patch 场景下 $B_{net}$ 往往是瓶颈，尤其在 4G 或弱 Wi-Fi 环境下。把高频更新内容单独成 Chunk，能让 $S_{chunk}$ 尽量小，$T_{dl}$ 也随之下降。

3. Patch / DLC 更新

那晚的 1.8GB 惨案之后，老周重新梳理了 Patch 和 DLC 的更新链路。Patch 是替换已有 Chunk 中的内容，DLC 是新增 Chunk。两者的 Pak 文件命名规则不同，分发系统的处理逻辑也不同。

Patch 的核心问题是稳定性。如果一次小更新改动了 Chunk 0 里的一张贴图，平台方会重新生成整个 Chunk 0 的差异包。玩家端需要下载的其实是差异数据，但如果 Chunk 划分不合理，差异包可能接近完整包。

DLC 的核心问题是隔离性。DLC 资源应该尽量少引用基础包之外的资产。如果 DLC 里的角色皮肤引用了基础包里的一把武器材质，那玩家购买 DLC 时就必须同时更新基础包，否则运行时会出现软引用失败。这种耦合会让版本管理变成噩梦。

老周给团队定了一条规矩：DLC 只向上依赖，不横向依赖。每个 DLC Chunk 可以引用 Chunk 0 和共享 Chunk 10 的内容，但不能引用其他 DLC Chunk 的内容。这样做的好处是 DLC 可以独立下架、独立更新、独立回滚。

sequenceDiagram
    participant Player as "玩家客户端"
    participant Launcher as "游戏启动器"
    participant CDN as CDN
    participant Game as "游戏进程"

    Player->>Launcher: 启动游戏，检查版本
    Launcher->>CDN: 请求 manifest
    CDN-->>Launcher: 返回 Chunk 签名列表
    Launcher->>Launcher: 对比本地签名
    alt 基础包 Chunk 变化
        Launcher->>CDN: 下载差异 Pak
        CDN-->>Launcher: 返回 Patch 数据
    else DLC Chunk 缺失
        Launcher->>Player: 提示有可下载内容
        Player->>Launcher: 确认购买 / 下载
        Launcher->>CDN: 下载 DLC Pak
        CDN-->>Launcher: 返回 DLC 数据
    end
    Launcher->>Game: 启动并挂载 Pak
    Game->>Game: Asset Manager 注册新 Chunk

这个序列图展示了 Patch 和 DLC 在启动器阶段的差异。Patch 是静默的、差异化的；DLC 是显式的、整包下载的。把这两条路分开，玩家不会被一个 80MB 的补丁吓到 1.8GB。

阿杰后来补了一个细节：DLC 下载过程中要给玩家进度反馈。一个 800MB 的 DLC 如果拆成 4 个 200MB 的 Chunk，启动器可以按 Chunk 粒度汇报进度，而不是等到最后才显示 100%。这种粒度感对留存很重要。

4. Chunk 大小与下载优化

Chunk 大小不只是文件大小的问题，它关系到下载断点续传、CDN 缓存命中率、安装包压缩率和运行时 IO 模式。

老周分析过项目日志，发现移动端的下载失败率在 Chunk 大于 400MB 时明显升高。原因不是网速慢，而是后台进程被系统杀死。Android 和 iOS 对后台下载都有时间限制，单个任务拖得太长，系统就清理进程。把大 Chunk 切成多个小 Chunk，启动器可以逐个完成任务，降低被系统中断的概率。

但切得太碎也有代价。每个 Pak 文件都有文件头和索引，太小的话头尾开销会占掉不少空间。而且运行时加载多个小文件，Seek 次数增加，机械硬盘和低配移动设备会吃瘪。

老周的折中方案是按内容类型设定大小上限：

• 基础包 Chunk 0：尽量完整，控制在 1GB 以内。
• 共享依赖 Chunk 10：按材质包、动画包细分，单个 100MB 到 300MB。
• 活动资源 Chunk 40：按活动拆分，单个 50MB 到 200MB。
• DLC Chunk 50：按 SKU 拆分，单个 100MB 到 400MB。

下载优化还有一个容易被忽略的点：压缩。Pak 文件默认用 Zlib 压缩，对纹理和音频效果一般。如果项目使用了 Oodle 或 Brotli，需要在 DefaultEngine.ini 里配置压缩级别。压缩率越高，下载包越小，但解压 CPU 开销越大。老周在移动端的测试数据显示，Oodle Kraken 级别 4 能把 Pak 体积减少 18%，而解压时间只增加 5%。

flowchart TD
    A["原始资产"] --> B{按 Label 分组}
    B -->|"核心内容"| C["Chunk 0"]
    B -->|"共享依赖"| D["Chunk 10"]
    B -->|"武器皮肤"| E["Chunk 20"]
    B -->|"活动资源"| F["Chunk 40"]
    B -->|"DLC 内容"| G["Chunk 50"]
    C --> H[Cook]
    D --> H
    E --> H
    F --> H
    G --> H
    H --> I["Pak 打包"]
    I --> J{单 Pak 是否超过阈值}
    J -->|"是"| K["拆分为多个子 Pak"]
    J -->|"否"| L["生成签名文件"]
    K --> L
    L --> M["上传 CDN"]

这个流程图把 Chunk 分组、Cook、Pak 打包、上传 CDN 的完整链路串了起来。关键判断在 J 节点：单个 Pak 超过阈值就要拆分。老周把阈值配成 300MB，构建脚本会自动在末尾追加 _001、_002 这样的后缀。

5. Asset Manager 中配置 Chunk

配置 Primary Asset Labels 有两种方式：在编辑器里创建 Label 资产，或者在 DefaultGame.ini 里写规则。老周建议大规则用 Label 资产，临时覆盖用 INI。

创建一个 Label 资产很简单：Content Browser 右键 -> Miscellaneous -> Primary Asset Label。命名为 L_Weapons_Core，然后在属性面板里填：

• Chunk ID: 20
• Priority: 10
• Apply Recursively: true
• Explicit Assets: 把 /Game/Weapons/Core/ 下的数据资产拖进去

Apply Recursively 这个选项很关键。如果勾选，所有被这些 Primary Asset 引用的 Secondary Asset 也会进入 Chunk 20。不勾选的话，只有 Primary Asset 本身进去，Secondary Asset 会按默认规则走，大概率回流到 Chunk 0，前面说的共享依赖问题就会出现。

INI 配置则适合批量规则。下面是一段示例：

[/Script/Engine.AssetManagerSettings]
PrimaryAssetTypesToScan=(PrimaryAssetType="Weapon",AssetBaseClass=/Script/MyGame.WeaponData,Directories=((Path="/Game/Weapons/Data")),Rules=(Priority=-1,ChunkId=-1,bApplyRecursively=True,CookRule=AlwaysCook))
PrimaryAssetTypesToScan=(PrimaryAssetType="Skin",AssetBaseClass=/Script/MyGame.CharacterSkin,Directories=((Path="/Game/Characters/Skins")),Rules=(Priority=-1,ChunkId=-1,bApplyRecursively=True,CookRule=AlwaysCook))

[/Script/Engine.PrimaryAssetLabel]
+LabelAssets=(Label="WeaponsCore",ChunkId=20,Priority=10,ApplyRecursively=True,AssetCollection="/Game/Weapons/Core")
+LabelAssets=(Label="SeasonWinter",ChunkId=40,Priority=20,ApplyRecursively=True,AssetCollection="/Game/Events/Winter2026")

注意 PrimaryAssetTypesToScan 里的 ChunkId=-1 表示默认不指定 Chunk，具体归属交给 Label 决定。如果这里直接写死 ChunkId，会和 Label 产生冲突，Priority 规则就派上用场了。

Priority 的数值规则是：数值越大优先级越高。如果一个资产同时命中 ChunkId=20 的 Label 和 ChunkId=40 的 Label，优先级高的那个会覆盖另一个。老周建议给 Label 优先级分组：基础规则用 10，季节活动用 20，DLC 用 30，紧急补丁用 40。这样后续新增规则不会覆盖旧的稳定规则。

实际配置时还会出现另一种情况：一个资产被 Label 命中，同时又被 PrimaryAssetTypesToScan 显式指定了 ChunkId。默认行为下 Label 的优先级高于 PrimaryAssetTypesToScan，除非 Label 的 Priority 特别低。老周的习惯是把 PrimaryAssetTypesToScan 里的 ChunkId 统一设成 -1，让它只做资产扫描，不抢 Label 的分配权。扫描路径也尽量宽泛，允许 Label 在后期做精细裁剪。

配置完成后一定要跑一遍 Asset Audit 工具。UE5.8 的 Content Browser 里右键资产 -> Asset Actions -> Audit Assets，可以看到每个资产最终落在哪个 Chunk。老周每次调整 Label 都会扫一遍 Audit，确认没有资产漏回 Chunk 0，也没有共享材质被重复塞进多个 Chunk。

6. 运行时加载特定 Chunk

配置好 Chunk 只是第一步。玩家购买 DLC 或进入某个地图时，游戏进程需要主动挂载对应的 Pak Chunk，并通知 Asset Manager 这些资产现在可用了。

挂载 Pak 通常用 FPakPlatformFile 接口：

#include "IPlatformFilePak.h"
#include "HAL/PlatformFilemanager.h"

bool UMyContentManager::MountChunkPak(int32 ChunkId)
{
    const FString PakPath = FPaths::ProjectPersistentDownloadDir()
        / FString::Printf(TEXT("pakchunk%d-Windows.pak"), ChunkId);

    FPakPlatformFile* PakFile = (FPakPlatformFile*)
        FPlatformFileManager::Get().GetPlatformFile(TEXT("PakFile"));

    if (PakFile && FPaths::FileExists(PakPath))
    {
        return PakFile->Mount(*PakPath, 0, *FString::Printf(TEXT("%d"), ChunkId));
    }
    return false;
}

挂载之后，Asset Manager 还需要刷新资产索引。UE5.8 提供了 UAssetManager::ScanPathsForPrimaryAssets 和 GetPrimaryAssetIdList 来让新挂载的资产进入可加载状态。

void UMyContentManager::LoadDLCAssets(int32 ChunkId)
{
    if (MountChunkPak(ChunkId))
    {
        UAssetManager& AssetManager = *UAssetManager::GetIfValid();
        TArray<FPrimaryAssetId> DLCAssets;
        AssetManager.GetPrimaryAssetIdList(TEXT("Skin"), DLCAssets);

        FStreamableDelegate OnLoaded;
        OnLoaded.BindUObject(this, &UMyContentManager::OnDLCReady);

        AssetManager.LoadPrimaryAssets(DLCAssets, TArray<FName>{}, OnLoaded);
    }
}

这段代码只有十几行，但老周踩过两个坑。第一，MountChunkPak 的路径在不同平台上后缀不同，Windows 是 -Windows.pak，Android 是 -Android.pak，iOS 是 -IOS.pak。第二，加载完成委托触发时，资产对象已经可用，但 UI 蓝图可能还没有刷新绑定，需要手动调用 BlueprintUpdate。

运行时卸载 Chunk 更麻烦。Pak 文件挂载后，如果里面有资产被 UObject 硬引用，直接卸载会导致崩溃。老周的做法是：卸载前先清空引用，等待下一帧 GC，再调用 Unmount。这个流程在 UI 关闭、地图切换时特别重要。

7. 版本兼容与回滚

DLC 和 Patch 都会引入版本兼容问题。一个冬季活动 DLC 可能只在 1.4.0 版本上工作，如果玩家停留在 1.3.0，启动器需要提示他先更新基础包。这种依赖关系要在 manifest 里显式声明。

老周的 manifest 结构大致如下：

{
  "version": "1.4.0",
  "chunks": [
    { "id": 0, "hash": "a1b2c3", "size": 1024000000, "min_app_version": "1.0.0" },
    { "id": 40, "hash": "d4e5f6", "size": 150000000, "min_app_version": "1.4.0" },
    { "id": 50, "hash": "g7h8i9", "size": 300000000, "min_app_version": "1.4.0" }
  ]
}

min_app_version 字段是核心。启动器对比客户端版本和每个 Chunk 的最低版本，不满足就拒绝挂载，并引导玩家更新。没有这个字段，旧客户端加载新 DLC 时会在 Asset Manager 解析阶段直接崩溃。

回滚机制也依赖 manifest。如果某个 Patch 上线后发现严重 bug，老周会让 CDN 把对应 Chunk 的 hash 回滚到上一个稳定版本。玩家下次启动时，启动器发现本地 hash 与新 manifest 不符，会重新下载旧版本数据。整个过程中游戏代码不需要改动，因为 Primary Asset ID 和 Chunk ID 没有变，变的只是 Pak 内容。

graph LR
    A["Chunk 40 v1.4.0"] -->|"发现 bug"| B["回滚 hash 到 v1.3.9"]
    B --> C["CDN 替换 Pak"]
    C --> D["玩家启动器校验失败"]
    D --> E["重新下载 v1.3.9 的 Chunk 40"]
    E --> F["Asset Manager 正常加载"]
    G["Chunk 50 DLC"] --> H["独立 hash 链"]
    H --> I["不影响基础包和活动包"]

这个图说明回滚可以局限在单个 Chunk。DLC 的 hash 链独立存在，不会污染基础包。老周把这套流程做进了 Jenkins 流水线，每次构建自动生成 manifest 并上传到 CDN 的 versioned 目录。

8. 平台差异（主机/PC/移动）

最后说说三端差异。主机、PC、移动在 Pak 挂载、Chunk 大小、下载策略上都有不同约束。

主机平台（PS5 / Xbox Series X|S）对文件 IO 要求最严格。它们支持高速 SSD，但 Pak 文件需要符合平台特定的文件布局。索尼和微软都有自己的补丁格式，虚幻的 Chunk 分组需要与平台补丁工具对齐。老周的经验是：主机 Patch 尽量让 Chunk 边界与平台的最小补丁单元对齐，否则一个 5MB 的改动可能被平台打包成 200MB 的增量包。

PC 平台最自由，Steam、Epic、自家启动器都支持自定义差异更新。缺点是用户环境千差万别，机械硬盘、SSD、网络质量参差不齐。老周在 PC 上保留了较大的 Chunk 粒度，同时提供可选的 HD 材质包作为独立 DLC，让低配玩家可以选择不下载。

移动端最纠结。包体大小直接影响商店转化率，但拆得太碎又影响加载。iOS 有 ODR 和 App Slicing，Android 有 Play Asset Delivery。UE5.8 的 Chunk 编号可以和这些平台机制映射。老周的做法是：Chunk 0 作为初始安装包，严格控制大小；Chunk 10 到 40 作为快速跟随资源，玩家在首次启动后后台下载；Chunk 50 以上的 DLC 按需下载。

移动端还需要考虑内存预算。低端设备的 RAM 可能只有 4GB，同时挂载多个大 Chunk 会触发系统杀进程。老周在 Android 上限制了同时挂载的 Pak 数量，超过上限时按 LRU 卸载。这个逻辑封装在一个 UMobileChunkLimiter 类里，根据设备 profile 动态调整。

Switch 平台比较特殊。它的卡带版和数字版在读取速度上有差异，卡带读取连续大文件更快，数字版安装在小容量存储上时随机读取会吃亏。老周给 Switch 单独准备了一套 Chunk 拆分策略，把频繁共用的资源集中到一个 200MB 左右的 Chunk 里，减少卡带寻道。这个数字版玩家虽然要多下一点初始包，但运行时的加载抖动会少很多。

不同平台的 Pak 文件名后缀、压缩算法、签名方式都要在构建脚本里区分。老周的 Jenkins 流水线会读取 BuildConfig.json，按平台输出三套产物，分别上传到对应的 CDN 目录。PC 用 -Windows.pak 和 Zstd，主机用平台指定格式，移动用 Oodle 或默认 Zlib。最终 manifest 也按平台拆分，避免启动器下载错包。

平台	推荐 Chunk 大小	更新机制	特殊注意
PS5 / Xbox	100MB - 1GB	平台原生补丁	与平台最小补丁单元对齐
PC	100MB - 500MB	启动器差异下载	提供可选 HD 包
iOS / Android	25MB - 200MB	Play Asset Delivery / ODR	控制初始包体，后台下载

这个表是老周团队内部的分发规范。不同平台的 Pak 后缀、压缩算法、签名方式都不一样，构建脚本会用同一个 Chunk 配置生成三套产物。

收尾

那晚的会议开到了凌晨两点。老周最后把白板上的八个字改成了：标签管归属，Chunk 管发布。

Primary Asset Labels 解决的是资产该进哪个 Chunk 的问题。Chunk 划分解决的是发布单元该多大、何时更新、如何回滚的问题。两者都不复杂，但需要在项目早期就定好规则。等到包体失控、Patch 爆炸、DLC 互相拉扯时再回头改，代价会高很多。

小林后来负责维护这套 Label 配置，每次新增活动或 DLC 都会先填一张资产归属表。阿杰把构建脚本和 manifest 生成接进了 CI，每次合并到 main 分支自动出包。老周则定期检查 Patch 差异报告，确保没有小改动牵动大 Pak。

UE5.8 的 Asset Manager 给了项目足够的控制力，但控制力本身不会自动产生秩序。秩序来自团队对规则的坚持，以及对每次构建结果的审视。