RevHotUpdate · 资源热更新系统技术方案

0结论速览

一句话：这不是"再造一个 YooAsset"，而是把框架 README 里已经写明的那条扩展路（IRevResPolicy + IRevResLoader）真正做出来，并且做得连策略都不用换 —— 只换"包从哪来"。

1需求拆解与边界

1.1 你提的 7 件事，逐条落到能力

1.2 明确不做（边界清单，附理由）

2现状盘点：框架已经给了什么、缺什么

2.1 ✅ 已具备（都有代码证据，可直接复用）

2.2 ❌ 缺的（本方案要补的，全在"包外"）

2.3 一句话总结现状

3三个必须承认的硬事实（可行性的关键判断）

3.1 事实一：复用框架加载器 = 需要一个"路径钩子"，而且这是唯一的正确接法

证据链（三步）：

1. RevABLoader.LoadBundle(string) / LoadBundleAsync(string) 是 private static，路径由 private static StreamingRoot 拼出（RevABLoader.cs:61,113,442）→ 外部无法重定向；
2. 包级引用计数、依赖递归、并发合并、异步全在 RevABLoader 内部（_bundles / _loading）→ 重写一遍等于重写整个加载器（约 460 行，且要重做平台分派）；
3. 释放链路是 RevResManager.ReleaseBundleOf(handle) → handle.BundleLoader.ReleaseBundle(name)，而 handle.BundleLoader 的类型是具体类 RevABLoader、字段是 internal（RevResHandle.cs:41-43、RevResManager.cs:671-681）→ 自定义加载器无法参与这套生命周期管理（连"把引用挂到句柄上"都做不到，internal 挡住）。

结论：

• 方案 A（推荐）：框架给 RevABLoader 加一个静态钩子 BundlePathResolver（约 8 行，默认 null 行为不变）→ 热更包零侵入复用整条加载链路，RevResBootstrap.ShutdownAll() 也能正常释放我们的包；
• 方案 B（零改动退路）：热更包自研 policy + loader，自己维护包级引用计数 —— 因为拿不到"资源释放"的回调（BundleAcquired 是 internal），只能自己扫 RevResManager.CachedHandles（公开）+ handle.RealPath（公开，格式 包名|资源名）反推存活集合，在版本切换/回登录时手动触发包回收。功能能跑通，但代码量约 +250 行、生命周期语义变模糊、且和框架的自动卸载门卫存在时序耦合。

3.2 事实二：ResMap 必须能热更，否则"新增资源"做不到

今天的链路：RevResBootstrap.LoadResMap() 从 Assets/Revolution/Resources/ResourceSystem/ResMap.txt 读表 → 这张表随包体发布、运行时只读。

如果热更只更新 AB 包、不更新映射表，那么"这次热更新增了一张 UI 图"这件事就没有任何办法被业务加载到（逻辑路径根本查不到）→ 产品上表现为"热更成功但新资源加载失败"。

所以 ResMap.txt 必须作为热更文件之一下发，并在加载器建表时覆盖内置表（策略：热更表优先 + 内置表兜底，见 5.7）。这需要框架的第 2 个钩子（RevResBootstrap.ResMapOverride）。

3.3 事实三：Android 的首包不能直接 LoadFromFile（jar 路径问题）

• 桌面 / iOS：Application.streamingAssetsPath 是真实文件目录 → AssetBundle.LoadFromFile 可用（框架现状 OK）；
• Android：streamingAssetsPath == "jar:file:///data/app/<包名>.apk!/assets" → File.Exists / LoadFromFile 都不是文件系统语义（框架 RevABLoader.cs:119-121 的注释也承认"File.Exists 不可用，直接尝试加载"，实际能否成功取决于 AB 是否被 APK 压缩，不可靠）；
• WebGL：没有本地文件概念 → 只能 UnityWebRequest（框架已按这个分支实现）。

解法（本方案的核心设计之一）：

4总体架构

4.1 分层与数据流

                      ┌──────────────────────── 业务只碰这一层 ────────────────────────┐
                      │   await RevHotUpdate.InitializeAsync(config, onProgress)       │
                      │   （之后照旧：RevResManager.LoadAsync<Sprite>(路径, cb, 分组)）│
                      └───────────────────────────────┬───────────────────────────────┘
                                                      │
   ┌──────────────────────── 热更包 Revolution.HotUpdate（新增）────────────────────────┐
   │  门面 RevHotUpdate ── CheckAsync 检查更新 → UpdateAsync 下载 → Install 装钩子      │
   │      │                                                                           │
   │      ├─ 清单层 RevHotManifest（解析/序列化/版本比对；纯 C#，可工程外断言）          │
   │      ├─ 下载层 RevHotDownloader（并发 3 / 重试 / 退避 / 超时 / 多源 / Range 续传）  │
   │      ├─ 校验层 RevHotVerifier（尺寸 + SHA-256 流式分帧；可选复用 .manifest 的 CRC） │
   │      ├─ 存储层 RevHotStore（版本目录 / tmp / 原子提交 / current 指针 / 清理）       │
   │      └─ 桥接层 RevHotResBridge（设框架的 2 个静态钩子 → 触发一次 RevResBootstrap.Init）│
   └───────────────────────────────┬───────────────────────────────────────────────────┘
                                   │  钩子（默认 null，不装热更包时行为与现在完全一致）
   ┌───────────────────────────────▼───────────── 框架 Revolution.Runtime（不改加载逻辑）┐
   │  RevResBootstrap.Init → RevABResPolicy(映射表, RevABLoader) → RevResourcesResPolicy  │
   │  RevABLoader：依赖递归 / 包级引用计数 / 并发合并 / RevTask 异步 / 平台分派            │
   │  RevResManager：资源级引用计数 / 分组卸载 / 缓存 / 延迟释放                          │
   └─────────────────────────────────────────────────────────────────────────────────────┘

   远端（COS / OSS / CDN）：
     {RemoteRoot}/{环境?}/{平台}/{大版本}/{渠道?}/RevHotManifest.txt   ← 版本清单（唯一真相，最后上传）
     {RemoteRoot}/{环境?}/{平台}/{大版本}/{渠道?}/bundles/hero          ← AB 包（内容寻址，可长缓存）
     {RemoteRoot}/{环境?}/{平台}/{大版本}/{渠道?}/ResMap.txt            ← 映射表（热更它 = 支持新增资源）
     ★ "大版本"这一段是隔离墙：旧客户端的请求永远落在自己的目录里（见第十六章）

4.2 包目录结构（新增，与框架/示例并列）

Assets/Revolution.HotUpdate/
├── package.json                          # 可选：UPM 发布用（name: com.revolution.hotupdate）
├── README.md                             # 3 分钟上手
├── Runtime/                              # asmdef: Revolution.HotUpdate（references: Revolution.Runtime）
│   ├── Facade/RevHotUpdate.cs            # 业务唯一入口：CheckAsync / UpdateAsync / Install / Progress
│   ├── Core/
│   │   ├── RevHotConfig.cs               # 配置（远端根 / 多源 / 并发 / 超时 / 校验 / 保留版本数…）
│   │   ├── RevHotManifest.cs             # 清单数据结构 + 解析 + 序列化（纯 C#）
│   │   ├── RevHotBundleInfo.cs           # 单个包：name/hash/size/deps/tags/builtin
│   │   ├── RevHotVersion.cs              # 版本号 + 平台 + minApp + 比较规则（纯 C#）
│   │   ├── RevHotPlan.cs                 # 差量计划：新增/变更/删除 三集合 + 需要下载的字节数
│   │   └── RevHotError.cs                # 失败原因枚举（热更自有，映射到框架的 BundleLoadFail）
│   ├── Download/
│   │   ├── RevHotDownloader.cs           # 并发调度 + 重试/退避 + 进度聚合
│   │   ├── RevHotSource.cs               # 下载源（主源 + 备用源，失败自动切换）
│   │   └── RevHotUrlBuilder.cs           # URL 拼装（远端根 + 平台 + 渠道 + 相对路径）
│   ├── Pipeline/
│   │   ├── RevHotVerifier.cs             # 校验（size / SHA-256 流式分帧 / 可选 CRC）
│   │   └── RevHotStore.cs                # 盘上布局：版本目录 / tmp / 原子提交 / 清理 / 首包落地
│   ├── Integration/
│   │   └── RevHotResBridge.cs            # 设框架钩子 + 调 RevResBootstrap.Init + 版本切换时的清理顺序
│   └── Support/
│       └── RevHotUpdateUnityHooks.cs     # 进 Play 复位钩子、清理残留 tmp（域重载纪律）
└── Editor/                               # asmdef: Revolution.HotUpdate.Editor（includePlatforms: [Editor]）
    ├── RevHotManifestBuilder.cs          # 读 AssetBundles/<平台> + *.manifest + ResMap.txt → 生成清单
    ├── RevHotUploadKit.cs                # 产出上传目录 + 生成上传命令（coscmd/ossutil/aws-cli 均可）
    └── Window/RevHotUpdateWindow.cs      # 面板：选平台/版本 → 生成清单 → 校验 → 打开目录 → 导出上传脚本

4.3 热插拔的 4 条机制（"不导入就零影响"怎么保证）

5核心设计逐项论证

5.1 盘上布局与版本目录

5.1.1 目录结构

{persistentDataPath}/RevHotUpdate/                 ← 默认加载根（可配置 LocalRootOverride）
├── current.txt                                     ← 当前生效的版本号（一行文本；原子替换）
├── <平台>/                                         ← PC / Android / iOS / WebGL（WebGL 不用这条）
│   ├── 1.0.3/                                      ← 版本目录（只读语义：写完就不再改）
│   │   ├── RevHotManifest.txt                      ← 本次生效的清单副本（排查用，加载时读它）
│   │   ├── ResMap.txt                              ← 热更映射表（5.7）
│   │   ├── bundles/hero                            ← AB 包（文件名 = 包名，与框架一致）
│   │   ├── .tmp/hero.part                          ← 下载中的半成品（同一个包一个文件，天然续传）
│   │   └── .stamp                                  ← 版本完成标记（所有文件校验通过后才写）
│   └── 1.0.2/                                      ← 上一个版本（保留 N 份，默认 2；回滚用）
└── .lock                                           ← 单实例锁（防止两个进程同时写版本目录）

5.1.2 三条纪律

1. 版本目录只写一次：所有文件下载 + 校验完成 → 写 .stamp → 才更新 current.txt；半成品版本永远不会被加载（加载只认 current.txt 指向且带 .stamp 的目录）。
2. current.txt 用"写临时文件 + 替换"的方式更新（File.Replace / 先删后移），避免断电写出半行文本。
3. 清理规则：启动时删掉 临时目录 里超过 7 天的 .part（上次没下完的），并保证"当前版本 + 上 1 个版本"之外的老版本目录被删（可配置 KeepVersions）。

5.1.3 加载路径解析（钩子的实现）

// RevHotStore.ResolveBundlePath（热更包内，静态方法 —— 不捕获实例，避免域重载后指向死对象）
internal static string ResolveBundlePath(string bundleName)
{
    // ① 当前生效版本目录里有 → 用它（热更下来的新包）
    string hot = Path.Combine(CurrentVersionDir, "bundles", bundleName);
    if (File.Exists(hot)) return hot;

    // ② 没有 → 首包兜底（桌面/iOS 的 StreamingAssets 是真文件；Android 已在首启落地到 persistentDataPath）
    return Path.Combine(FirstPackageDir, bundleName);   // 见 5.1.4
}

要点：

• "本地优先 + 首包兜底" 意味着只下载变化过的包，磁盘不再是"整份资源 × 2"；
• WebGL 下这个函数直接返回 {RemoteRoot}/{平台}/bundles/{包名}（远端 URL，框架的 WebGL 分支本身就吃 URL）→ WebGL 连落盘都不需要；
• 返回 null 表示"让它走框架默认路径"（存在这种场景：业务临时关掉热更）。

5.1.4 首包（内置资源）的三种模式

5.2 清单格式：为什么用行式文本，而不是 JSON

选它还有两个工程上的理由：

1. 框架自己的映射表（ResMap.txt，逻辑名|包名|资源名）就是这个风格（RevResBootstrap.cs:115-124）——同一套心智，不用记第二种格式；
2. 出问题时"用记事本打开比一比"就能定位（BuildManifest.json 定位是"给人/CI 看"的，清单则是"运行时真正吃的"，可读性值钱）。

完整样例见 附录 A。核心字段：

# RevHotManifest v1
@version|1.0.3
@platform|Android
@channel|official
@minAppVersion|1.0.0            ← 防"新资源配老包"（App 版本太低就强制更新包体）
@hashAlgo|sha256
@builtAt|2026-10-01 12:00:00
@bundleCount|128

@resmap|ResMap.txt|8f3c...|20481        ← 映射表本身也当热更文件（含 hash/size）
@bundle|hero|9a1b...|15728640|common,shader|builtin,hot
@bundle|ui_login|2c7d...|1048576|common|hot
...

5.3 版本比对与差量：算法（这是"只下变化的部分"的核心）

输入：远端清单 R（刚下载的）、本地清单 L（= 当前版本目录里的清单副本；没有则视为空）
输出：RevHotPlan { Add[]  Change[]  Remove[]  TotalBytes  ResMapChanged }

对每个 R.bundle：
    L 里没有同名包            → Add（新增）
    L 里有，但 hash 不同       → Change（内容变了）
    L 里有，hash 相同          → 跳过（不下、不校验、不落盘）
对每个 L.bundle 而 R 里没有的 → Remove（标记为"下次清理时连同删除"）
R.resmap.hash != L.resmap.hash → ResMapChanged（必须下载，否则新资源加载不到）

TotalBytes = Σ(Add + Change 的 size)        → 用于给玩家显示"需要下载 XX MB"
若 TotalBytes == 0 且 !ResMapChanged        → 无更新，直接 Install 走人（零下载启动）

配套的产品化细节（都只有几行代码，但决定体验）：

• WIFI / 流量提示：RevHotUpdate.CheckAsync 返回的 TotalBytes 交给 UI 决定"是否现在就下"；
• 弱网/大包保护：Config.MaxBytesPerSession（超过就本次不下，提示稍后）—— 可选；
• 失败可恢复：没下完 / 校验失败 → 版本目录未打 .stamp，current.txt 没变 → 下次启动从 Change/Add 重新算一遍，已下好的包用 hash 比对跳过（天然支持"暂停/继续"）。

5.4 下载器设计（轻量但该有的都有）

// 核心：一个文件 = 一个 RevTask；并发由信号量控制；失败按指数退避重试；支持从 .part 续传
private async RevTask DownloadOneAsync(RevHotFileRef file, RevCancellationToken token)
{
    string part = _store.TempPathOf(file);
    long offset = RevHotStore.ExistingLength(part);           // 续传起点（0 = 从头下）
    string url  = _urlBuilder.Build(file.RemotePath);

    using (UnityWebRequest www = UnityWebRequest.Get(url))
    {
        if (offset > 0 && offset < file.Size)
            www.SetRequestHeader("Range", "bytes=" + offset + "-");   // COS/OSS 原生支持 Range
        else
            offset = 0;

        www.downloadHandler = new DownloadHandlerFile(part, append: offset > 0);  // ★ 落盘，不占内存
        www.timeout         = _config.TimeoutSeconds;
        await www.SendWebRequest();                            // RevTask 直接 await UnityWebRequestAsyncOperation
        if (www.result != UnityWebRequest.Result.Success)
            throw RevHotError.Network.Wrap(www.error, url);    // 上层决定换源 / 重试 / 中止
    }
    await _verifier.VerifyAsync(part, file, token);            // 尺寸 + hash（分帧，见 5.5）
    _store.Commit(part, file.LocalPath);                       // 原子 rename → 版本目录
}

5.5 校验：复用 Unity 已经算好的东西

两条路，默认只做第一条（够用且零成本）：

① 复用 Unity 生成的信息（零成本）

Unity 为每个包生成的 <包名>.manifest（纯文本）里已经带了 CRC 与 Hashes.AssetFileHash（MD5）。

我们的编辑器工具在生成清单时直接读这些字段填进 @bundle 行 —— 不需要自己实现 hash 计算，还能顺便用 CRC 做 AssetBundle.LoadFromFile(path, crc, 0) 的加载期校验（可作为可选钩子加在 BundlePathResolver 旁边）。

② 自己算 SHA-256（可选，推荐用于"防篡改 + 增量缓存"）

用 FileStream 分块读（1MB 缓冲），每帧最多算 N MB（默认 8MB/帧）→ 避免几百 MB 的包一次性把帧卡住；进度可复用"下载进度条"的尾部阶段。

校验策略配置：

public enum RevHotVerifyMode
{
    SizeOnly,      // 只比大小（最快，仅适合内网联调）
    Hash,          // 尺寸 + hash（默认；hash 算法取清单的 @hashAlgo）
    HashAndCrc,    // 再加 Unity 的 CRC（最严；加载期也校验）
}

5.6 加载重定向：框架侧钩子的完整 diff 草案

// ===== 文件：Runtime/RevResourceSystem/Implementation/Loaders/RevABLoader.cs =====
/// <summary>
/// 包路径重定向钩子：参数 = 包名，返回 = 该包的完整路径（本地文件路径，或 WebGL 下的 URL）；
/// 返回 null / 空串 → 走默认的 StreamingAssets/&lt;平台名&gt;/&lt;包名&gt;。
/// ★ 热更包用它把加载指到 persistentDataPath 的版本目录；本框架自身不使用它。
/// ★ 不设置时（默认 null）行为与从前完全一致 —— 对不装热更包的工程是零影响。
/// </summary>
public static Func<string, string> BundlePathResolver { get; set; }

private static string ResolveBundlePath(string abName)
{
    string custom = BundlePathResolver?.Invoke(abName);
    return string.IsNullOrEmpty(custom) ? StreamingRoot + abName : custom;
}

然后把现有 3 处 StreamingRoot + abName 换成 ResolveBundlePath(abName)：

5.7 ResMap 热更（让"新增资源"成立）

// ===== 文件：Runtime/RevResourceSystem/Support/RevResBootstrap.cs =====
/// <summary>
/// ResMap 映射表的覆盖来源（热更包用它把"逻辑名 → 包名|资源名"换成热更版本，从而支持新增资源 / 改包）。
/// 返回 null → 只用内置表。★ 不设置时行为与现在完全一致。
/// </summary>
public static Func<Dictionary<string, string>> ResMapOverride { get; set; }

private Dictionary<string, string> LoadResMap()
{
    var map = new Dictionary<string, string>();

    // ① 内置表（随包体发布）—— 原逻辑不变
    TextAsset ta = Resources.Load<TextAsset>("ResourceSystem/ResMap");
    if (ta != null) { /* 原样解析：按行、Trim、跳过 # 与空行、Split('|') */ }

    // ② ★ 热更表覆盖内置表（同名键覆盖；内置表里独有的键保留）
    //    合并而不是替换，是为了"新资源能热更 + 老资源不用重下"两边都要：
    //    热更表本身就包含全部条目（编辑器工具生成的是全量表），合并只是给"清单损坏/不完整"留一层兜底。
    Dictionary<string, string> hot = ResMapOverride?.Invoke();
    if (hot != null) foreach (KeyValuePair<string, string> kv in hot) map[kv.Key] = kv.Value;

    return map;
}

热更表从哪来：{版本目录}/ResMap.txt（下载下来的），解析逻辑与框架 RevResBootstrap 完全一致（同样的格式、同样的 # 注释与 Trim 规则）。解析这份表的代码有 2 份（框架 1 份 + 热更 1 份）—— 建议后续把它抽成 RevResMapReader 供两边共用（属于"可选的小重构"，不做也能跑）。

5.8 生命周期与卸载：完全交给框架

因为走的是"复用 RevABLoader"的路线，包级引用计数、资源的释放时机、版本切换时的清理顺序都由框架既有的机制负责：

// 版本切换（热更到新版本）时的正确顺序 —— 顺序错了会"卸载正在用的资源"
RevAsyncLoadPump.CancelAll();                 // ① 中断在途加载（否则新包还没落地就有人去读）
RevResPreloader.ReleaseAll();                 // ② 归还预加载持有
RevResManager.UnloadAll();                    // ③ 清资源缓存并归还包级引用
RevBootstrap 内部的 _abLoader.ReleaseAll();   // ④ 释放所有包 + 主包 Manifest（RevResBootstrap.ShutdownAll 已经做了 ①~④）
RevHotStore.Activate(newVersion);             // ⑤ 切 current.txt 指针
RevHotStore.DeleteOldVersions();              // ⑥ 删老版本目录（保留 KeepVersions）
RevResBootstrap.Instance.Init();              // ⑦ 重装策略（新清单/新映射表生效）

5.9 对象存储适配（COS / OSS / CDN）

原则：不引 SDK，只拼 URL。

配置长这样（换环境 = 改一个字符串）：

new RevHotConfig
{
    RemoteRoot    = "https://cdn.example.com/gameA",     // 主源（一般是 CDN，回源到 COS/OSS）
    FallbackRoots = new[] { "https://bucket-1250000000.cos.ap-guangzhou.myqcloud.com/gameA" },  // 直连兜底
    Channel       = "official",                          // 可选：分渠道（.../<平台>/<渠道>/）
    ExtraHeaders  = new Dictionary<string, string> { ["x-game-token"] = "..." },  // 可选：临时令牌
}

三条实践纪律（都是踩过坑的）：

1. 清单别长缓存：RevHotManifest.txt 请求带 ?t={unix秒} 或让 CDN 对该路径设 Cache-Control: no-cache；包文件用长缓存（因为文件名/版本目录变了内容就变了，是 immutable 的）；
2. 上传顺序：先传所有内容（包 + ResMap），最后传清单 —— 清单是"原子切换开关"；反之会出现玩家拉到"半新半旧"的组合；
3. CORS（WebGL 必需）：COS/OSS 的跨域规则要放开 GET、Range、以及你们自定义的 Header，否则小游戏/网页端会以"网络错误"的形式失败（排查时非常费时间）。

5.10 安全与合规

5.11 编辑器侧工具（清单生成是核心）

// RevHotManifestBuilder：输入是"框架打包工具的产物"，输出是一份可直接上传的清单
//   输入：AssetBundles/<平台>/          （ABBuildSetting.GetOutputDir）
//         <平台>/<包名>.manifest         （Unity 原生清单：CRC / AssetFileHash / Dependencies）
//         <平台>/BuildManifest.json      （框架的产物清单：version / buildTime）
//         Assets/Revolution/Resources/ResourceSystem/ResMap.txt（框架生成的映射表）
//   输出：<输出目录>/RevHotManifest.txt + 复制一份 ResMap.txt + 校验报告
[MenuItem("Revolution.Tools/热更新/生成热更清单", false, 10)]
public static void Build() { ... }

面板（RevHotUpdateWindow）提供 5 个动作：

5.12 可观测性（沿用框架的风格）

RevHotUpdate.State          // Idle / Checking / Downloading / Verifying / Applying / Ready / Failed
RevHotUpdate.LastError      // RevHotError（含分类 + 人话消息 + 出错的 URL / 文件名）
RevHotUpdate.Dump()         // 一行行地打出：远端版本、本地版本、计划集合、每包状态（照 RevLog.Dump 的味道）
RevLog 出口                 // tag = "HotUpdate"；失败必带原因（不打日志也不静默失败）

失败分类（沿用框架"失败必带原因"的纪律）：

5.13 顺带说明：代码热更怎么接（本方案不堵这条路）

// 资源热更做完之后，代码热更（HybridCLR）只需要把 dll 当普通资源：
RevResManager.LoadAsync<TextAsset>(RevResPath.HotCode, "GameLogic", ta =>
{
    System.Reflection.Assembly.Load(ta.bytes);      // 10 行接入，本文档不展开
}, RevResGroup.Config);

也就是说：热更包负责"把文件搬到本地并保证完整"，代码热更负责"加载程序集" —— 两者是叠放关系，不冲突。这也是把"只做资源热更"作为本期边界的底气。

6对外 API 草案（业务只用 3 个入口）

6.1 最省事（推荐，5 行）

// 放在启动流程最前面（比 RevResBootstrap.Init 早 —— 热更包内部会替你把 Init 的时机安排对）
RevHotUpdateResult r = await RevHotUpdate.InitializeAsync(
    new RevHotConfig
    {
        RemoteRoot = "https://cdn.example.com/gameA",
        // 其余全默认：平台目录自动判定 / SHA-256 校验 / 并发 3 / 重试 3 次 / 保留 2 个版本
    },
    onProgress: p => loadingBar.Set(p.Percent, p.Text));      // p.Text 例如 "正在更新 3/12 · 12.4 MB / 48.1 MB · 2.3 MB/s"

if (!r.Success) { tips.Show($"更新失败：{r.Error}"); return; }   // r.Error 已是一句人话
// 之后照旧写业务：RevResManager.LoadAsync<Sprite>(RevResPath.UI_Icon, "Hero_1001", cb, RevResGroup.UI);

6.2 进阶（分步，UI 自己掌控）

// ① 只检查（不下载）：拿"要不要更新 / 多大 / 什么版本"去做提示弹窗
RevHotCheckResult check = await RevHotUpdate.CheckAsync(config);
if (!check.HasUpdate) { RevHotUpdate.Install(); return; }

// ② 玩家确认后再下（WIFI 策略、大包提示都在这层做）
if (!check.ResMapChanged && check.TotalBytes > 50 * 1024 * 1024 && !IsWifi())
{
    if (!tips.Ask($"本次更新 {check.TotalBytesText}，建议在 WIFI 下进行")) return;
}

// ③ 下载 + 校验 + 落地（可取消：token 来自框架的 RevCancellationTokenSource）
RevHotUpdateResult r = await RevHotUpdate.UpdateAsync(check, tokenSource.Token, onProgress);

// ④ 生效（装钩子 + 重装策略；内部会先 ShutdownAll 再 Init）
if (r.Success) RevHotUpdate.Install();

6.3 配置对象（字段 + 默认值）

6.4 与框架的调用顺序（必须照这个顺序）

App 启动
  │
  ├─ ①（可选）RevLog.EnableFileLog(...)          ← 热更期间日志落盘，真机排查靠它
  ├─ ② await RevHotUpdate.InitializeAsync(cfg)   ← 拉清单 → 比对 → 下载 → 校验 → 落地
  │        └─ 内部：RevHotResBridge.Install()
  │               ├─ RevABLoader.BundlePathResolver = RevHotStore.ResolveBundlePath
  │               ├─ RevResBootstrap.ResMapOverride   = RevHotStore.BuildResMap
  │               ├─ RevResBootstrap.Instance.Init()          ← 框架原样装配（策略 + 自动卸载门卫）
  │               └─ （若有更新）先 ShutdownAll() 再 Init()，确保新映射表/新包路径生效
  ├─ ③ 业务 Init（UI/场景/配置表…）              ← 此时加载的就是"热更后的资源"
  └─ ④ 进游戏

7开发计划（4 阶段 + 验收标准）

8验证方案

8.1 工程外纯 C# 断言（沿用框架既有习惯，跑完即删临时工程）

8.2 真机验收清单

8.3 破坏性测试（必做 8 项）

1. 下载中断网 → 重连后从断点继续（.part 长度对得上）；
2. 下载中杀进程 → 下次启动自动续传；
3. 手动改坏一个已下好的包 → 校验失败 → 重下 → 成功；
4. 手动篡改清单里的 hash → VerifyFailed（不静默加载）；
5. 磁盘写满 → DiskFull（预检拦下，不留半成品版本）；
6. 远端清单只有半个文件（上传中被读到）→ ManifestInvalid，且旧版本照常能玩（current.txt 没动）；
7. 回滚：把 current.txt 指回上一版本 → 加载的是老资源（保留版本策略生效）；
8. CDN 主源 404 / 超时 → 自动切备用源完成更新。

9风险与对策

10与 YooAsset 的对照

结论：不替换 YooAsset，也不打算做成它 —— 我们的目标是"用最小的面积，把框架缺的那一格补上"。

11框架侧需要的最小改动（diff 草案 + 零改动退路）

11.1 改动清单（2 个文件，共约 15 行）

两处都有三个共同特征：默认 null = 行为与现在逐字节一致；框架自身永不设置它们；不装热更包的工程感受不到任何差别。

11.2 断言守护（跟着进框架的脱机断言工程）

✓ 未设置 BundlePathResolver 时：解析结果 == StreamingRoot + 包名（逐平台）
✓ 设置后返回 null / 空串 → 仍走默认路径
✓ 未设置 ResMapOverride 时：LoadResMap 结果与旧实现一致（键值全等）
✓ 设置后返回空表 → 与未设置等价；返回部分表 → 内置表独有键保留（合并语义）

11.3 如果坚持"框架一行都不改"（方案 B 的代价，供决策）

12目录与产出物清单

13需要拍板的 5 个决策（每条已给推荐）

14按包标记来源的简化方案（第一档：分工层）

14.1 先回答"行不行"

所以：行，而且是推荐的起步方式。 但它解决的问题是"加载从哪来"，不是"新包怎么来"。

14.2 ⚠️ 一处必须改的语义（否则新装机必崩）

你原话是"需要热更新的就从持久化路径当中来加载"。如果严格按字面实现（热更包只认持久化路径），会遇到一个致命场景：

新装机 / 首次启动 / 玩家清了数据 / 换机
  → {persistentDataPath} 是空的
  → 所有"热更包"全部 BundleLoadFail
  → 首包连登录界面都拉不起来（如果登录 UI 在热更包里，直接黑屏）

推荐把标记语义定成"允许被覆盖"（overridable），而不是"必须从某处读"。这带来三个额外好处：

1. 新装机、清数据、换机不用特殊处理（都是"回退内置"这条路径）；
2. 可以"临时关掉热更"（把持久化目录删掉/改个名就回到出包状态）——排查神器；
3. 打包期不用纠结"这个包到底放哪"：非热更包 = 永不覆盖，热更包 = 内置一份 + 允许覆盖，两者都能跑。

14.3 标记配在哪、怎么变成运行时能读的东西

三条纪律：不改框架的打包窗口、不改包名、生成物写在工程侧（不在 Assets/Revolution 里）。

为什么生成物放工程侧的 Assets/Resources/（而不是框架目录、也不放 Assets/Revolution.HotUpdate/）：

• 放框架目录 = 热更包往框架里写东西，删热更包会留垃圾 ✗；
• 放 Assets/Revolution.HotUpdate/ = UPM 只读安装时写不进去（框架对生成物有同样的降级处理，见 ABBuildSetting.EnsureWritableForGeneratedCode）✗；
• 放工程 Assets/Resources/ = UPM 只读也能用、随包体发布（很小）、WebGL/Android 都能 Resources.Load ✓。

14.3.1 配置资产长什么样

[CreateAssetMenu(menuName = "Revolution/热更包配置", fileName = "RevHotUpdateConfig")]
public sealed class RevHotUpdateConfig : ScriptableObject
{
    [Tooltip("持久化根目录名（{persistentDataPath}/<这个名字>/bundles/<包名>）")]
    public string localRootName = "RevHotUpdate";

    [Tooltip("没有命中任何规则的包，默认算热更还是内置（推荐 hot：标多了不会崩，只是允许被覆盖）")]
    public bool defaultHot = true;

    [Tooltip("规则：从上往下匹配，命中即止。支持 精确名 / 前缀（以 * 结尾）")]
    public List<Rule> rules = new List<Rule>();

    [Tooltip("生成时顺带写入每个包的 hash 与大小（供运行时可选校验；实测 .manifest 字段齐全才准确）")]
    public bool writeHashColumn = true;

    [Tooltip("运行时是否对'从持久化加载的包'做一次 hash 校验（默认关：档 1 以轻为主）")]
    public bool verifyOnLoad = false;

    [Serializable]
    public sealed class Rule
    {
        public string pattern;   // "ui_*" / "hero" / "scene_arena"
        public bool hot;         // true = 允许被覆盖
    }
}

编辑器窗口 RevHotUpdateWindow（挂在 Revolution.Tools/热更新/热更包标记）提供 4 个动作：

14.4 生成物格式（HotBundles.txt）

# RevHotBundles v1 —— 由 RevHotUpdate 编辑器工具生成，请勿手改（改了会被下次生成覆盖）
# 字段：@key|value / @bundle|包名|来源(hot|builtin)|hash|字节数
@generatedAt|2026-10-01 12:00:00
@localRoot|RevHotUpdate
@default|hot
@rule|ui_*|hot
@rule|scene_arena|builtin
@bundleCount|6

@bundle|common|hot|7c1e...|1572864
@bundle|ui_login|hot|9b2f...|1048576
@bundle|ui_bag|hot|1a3d...|2097152
@bundle|hero|hot|5e6f...|15728640
@bundle|effect_battle|hot|8d9c...|8388608
@bundle|scene_arena|builtin|2b4a...|25165824

• 与 RevHotManifest（附录 A）同族，第二档升级时只是"多几列、多一份远端来源"，不需要换解析器；
• hash/字节数两列就是 14.6 第 1 条的"搬错包"防线，成本几乎为零（编辑器侧本来就在读 .manifest）。

14.5 运行时实现（三段 + 一条时序约束）

14.5.1 表

// RevHotBundleTable：解析 HotBundles.txt（找不到表 → 全部按 builtin，Warn 一次）
internal static class RevHotBundleTable
{
    private static readonly Dictionary<string, RevHotBundleEntry> _map = new ...;   // 包名 → {hot, hash, size}
    internal static bool IsHot(string bundleName);
    internal static string LocalRoot { get; }                                        // {persistentDataPath}/{@localRoot}
}

14.5.2 路径解析（钩子的实现，这一段就是整个方案的核心）

// 唯一入口：框架的 RevABLoader.BundlePathResolver 指向它
internal static string ResolveBundlePath(string bundleName)
{
    // ① 标记为"允许被覆盖"的包：持久化目录里有就用它（这就是"热更生效"）
    if (RevHotBundleTable.IsHot(bundleName))
    {
        string local = Path.Combine(RevHotBundleTable.LocalRoot, "bundles", bundleName);
        if (File.Exists(local))
        {
            LogOnce(bundleName, "热更");        // ★ 首次加载时打一条 Info：这个包此刻从哪来 —— 排查全靠它
            return local;
        }
        // 持久化没有 → 回退内置（新装机 / 没下过 / 临时关热更，都走这里）—— 见 14.2
    }

    // ② 其余（内置包、或热更包还没下）：保持框架原行为
    return null;                                // 返回 null = 让框架走 StreamingAssets/<平台>/<包名>
}

14.5.3 装配

public static void Install()
{
    RevABLoader.BundlePathResolver  = RevHotPaths.ResolveBundlePath;   // 静态方法，不捕获实例
    RevResBootstrap.ResMapOverride  = RevHotPaths.LoadLocalResMap;     // 持久化里有 ResMap.txt 就用它，否则返回 null
    RevResBootstrap.Instance.Init();                                   // 框架原样装配
}

LoadLocalResMap()：读 {LocalRoot}/ResMap.txt → 解析成 Dictionary<string,string> → 没有文件就返回 null（框架继续用内置表）。

为什么档 1 也要它：业务往持久化目录搬"新包 + 新表"时，如果表还是内置那份，"新增资源"照样加载不到（3.2 那条硬事实在档 1 依然成立）。

14.5.4 目录约定（档 1 扁平版）

{persistentDataPath}/RevHotUpdate/
├── bundles/<包名>        ← 允许被覆盖的包放这里（档 1：人工/工具搬；档 2：下载器写）
├── ResMap.txt            ← 可选：热更映射表（有就用它）
└── .tmp/                 ← 档 2 的下载临时目录（档 1 空着即可）

14.5.5 ★ 一条时序约束（必须遵守，否则会出诡异问题）

不许在"包正被使用"时替换它的文件。原因有两条，都很难排查：

1. Windows（编辑器 / PC 包）上，文件被 LoadFromFile 映射后替换会失败（文件锁）→ 表现为"更新成功但加载的还是旧内容"；
2. 即使替换成功，已经加载的包仍留在内存里，本次进程内不会生效 → 表现为"我明明覆盖了，怎么没变"。

正确顺序（档 2 会自动做，档 1 里由业务手工遵守）：

RevResBootstrap.Instance.ShutdownAll();   // ① 卸载所有资源与包（①②③④ 都被它封装了）
（写入/替换持久化目录里的包 + ResMap.txt）
RevResBootstrap.Instance.Init();          // ② 重装策略 → 新文件生效

14.6 四个必须一起做掉的细节（缺一个都会变成"偶尔出问题"）

14.7 验收标准（档 1 可独立验收）

工程外纯 C# 断言（20+ 条，照框架习惯）：表解析（含 # 注释 / 空行 / 字段不足 / BOM / \r\n）、规则匹配（精确 / 前缀 / 兜底默认值 / 规则顺序）、路径选择（hot+存在 → 持久化；hot+缺失 → 内置；builtin → 内置）、LocalRoot 拼装、缺表时的降级行为。

真机手工验证 5 条：

1. 把某个"热更包"的新版本（不同内容）拷进 {persistent}/RevHotUpdate/bundles/ → 重进 Play → 加载到新内容（并看到"来源：热更"的日志）；
2. 把该文件删掉 → 重进 Play → 回到内置内容（来源：内置）；
3. 一个包都不放 → 重进 Play → 一切与装热更包之前完全一样（验收"不导入零影响"）；
4. Android 真机：内置包能加载（14.6 第 2 条的方案生效）+ 热更包能被覆盖；
5. WebGL（若需要）：钩子返回 CDN URL 时能加载（这一条依赖第十一章钩子的 URL 语义）。

14.8 与第二档的关系、以及什么时候必须升级

什么时候必须从档 1 升到档 2：当"新包怎么进玩家手机"这件事不能再靠人工/外部更新器时 —— 也就是产品要求"玩家自己点一下更新、下完就能玩新版资源"。在那之前，档 1 已经完全能支撑：

• "我提前知道哪些包将来要改"（打包期就分好）；
• "测试同学手工换一版资源验证"（拷包 + 重进）；
• "同一份代码同时支持两种来源的包"（设备上混合加载）。

14.9 工作量与推荐

15最终推荐方案（一页纸，照这个做）

15.1 一张图看懂

启动
 └─ await RevHotUpdate.InitializeAsync(cfg)
      ├─ ① Android：把内置首包"落地"到持久化（幂等 + hash 跳过；PC/iOS 跳过这一步）
      ├─ ② 拉远端清单（失败/损坏 → 保持当前版本，玩家照常进游戏）
      ├─ ③ 版本比对 → 只下变化过的包（Range 续传 / 重试 / 多源降级）
      ├─ ④ 校验（尺寸 + SHA-256）→ .tmp 原子改名 → 全齐后打 .stamp
      ├─ ⑤ 原子切换 current.txt（旧版本保留 N 份，可回滚）→ 删更老的
      └─ ⑥ 装钩子：持久化优先 → 内置兜底 → 都没有才报错；ResMap 同步热更
           └─ RevResBootstrap.Init()  ← 框架原样装配，业务加载代码一行不改

15.2 九条设计决策（每条都附"为什么这样最稳"）

15.3 分期落地（每步独立可验收、都不返工）

15.4 "为了稳"清单（12 条；每条都在防一个具体故障）

15.5 "千万别做"清单（8 条）

1. 别让"热更包"只从持久化读 —— 新装机必崩（14.2）。
2. 别在包被使用时覆盖它的文件 —— 文件锁 + 内存不一致（15.2 第 9 条）。
3. 别用 File.WriteAllBytes 直接写最终文件名 —— 必须 .tmp → rename。
4. 别把对象存储的 ListObjects 当目录清单 —— 权限/延迟/无原子性，清单才是唯一真相。
5. 别忘了把 ResMap 放进更新内容 —— 否则"新增资源"永远加载不到。
6. 别把热更放在资源系统初始化之后 —— 那会先加载一整套旧资源，再被卸载重载。
7. 别在回调里做同步全量校验 —— 几百 MB 会直接卡帧，必须分帧流式。
8. 别给热更包加自己的资源加载 API（RevHotUpdate.LoadAsync<T> 之类）—— 一旦有了它会立刻长成"第二套资源系统"，与框架的引用计数/分组/自动卸载彻底分家。

15.6 对第十三章 5 个决策的最终选定

15.7 一句话总结

16版本模型：大版本锚定（大版本内热更，跨大版本重出包）

16.1 模型长什么样：两个版本号，一条隔离墙

App 大版本（= Player Settings 里的 Application.version，如 1.2.0）  ← 锚点：只由"重新出包"改变
资源版本（如 1.2.0.37）                                            ← 锚点之内：可热更、可多次、可回滚

1.2.0 出包（基线）
  ├─ 1.2.0.1  … 1.2.0.37        资源热更（只下变化的包；同一大版本内可回滚到任意保留版本）
  └─ 1.3.0 重新出包             ← 新的大版本：全新的远端目录，老客户端永远不会拉到它

远端目录：{RemoteRoot}/{环境?}/{平台}/{大版本}/{渠道?}/…     ← "大版本"这一段就是隔离墙

16.2 为什么这是最优的版本策略（五条论证）

附带收益：如果将来引入代码热更（HybridCLR），这个模型就是它的公共地基 —— "大版本"天然界定了"哪些变更属于同一个兼容窗口"，这正是代码热更最需要的语义（但 iOS 审核红线不变，本期边界仍是"只做资源热更"）。

16.3 需要落地哪些机制（5 条，都是小东西）

16.4 "大版本内能热更什么 / 必须重新出包"对照表（给策划与产品看）

16.5 这个模型给前面章节带来的简化

16.6 边界与纪律（5 条，踩了会白干）

1. 服务端必须按大版本返回清单（客户端带上自己的 Application.version；服务端不要"返回最新"）——否则旧客户端会拿到新资源清单；
2. 测试环境务必按大版本隔离 ——"测试同学用旧包、拉到新资源"是这类项目最常见、也最难查的一类"假 bug"；
3. 大版本内不要做资源布局破坏性重构 —— 包名大改、依赖结构重排留到下一个大版本；
4. 跨大版本不要复用远端包目录 —— 哪怕 hash 相同、看起来能加载，也会埋下"资源与代码接口不匹配"的雷；
5. 强更体验要提前设计 —— 包体大小、是否走"游戏内下载整包"、以及审核/渠道节奏，都不在框架范围内，但必须在发版流程里定死。

16.7 一句话

17平台核实：Android / 小程序上还需要"路径重定向"吗？

17.1 先把两个词分开（后面所有结论都建立在这个区分上）

17.2 平台矩阵（事实核实）

17.3 Android 核实：为什么"根"仍然必须可注入

推论链（每步都有依据）：

1. 热更生效 = "加载时读到的是下载落地后的那份"（这是热更的定义，没有别的做法）；
2. 而框架的加载根是编译期写死的：RevABLoader.cs:61 的 StreamingRoot（private static，永远指向 StreamingAssets/<平台名>/），LoadBundle / LoadBundleAsync 也都是 private static；
3. 所以在 Android 上必须有"一个点"能把根换成持久化目录 —— 要么框架给钩子（11 行），要么自研 loader（方案 B：因为 RevResHandle.BundleAcquired/BundleLoader 是 internal，拿不到释放回调，生命周期语义退化）；
4. 而这与"按包分流"无关：采用"首包全量落地 + 只用版本目录一个根 + 基线兜底"之后，解析逻辑变成固定的两级（当前版本根 → 基线根），没有配置表、没有按包标记。

所以在 Android 上：可以砍掉"按包标记"（第十四章降级为可选），不能砍掉"根注入"（第十一章那 11 行仍然要）。

17.4 小程序（WebGL）核实：为什么"重定向"恰恰是全部

推论链：

1. 小游戏里 AssetBundle.LoadFromFile / File.Exists 都不可用（框架自己那行注释：RevABLoader.cs:117），AB 只能通过 UnityWebRequestAssetBundle.GetAssetBundle(url, …) 拿到；
2. 而 url 的来源在框架里是 StreamingRoot + abName = {小游戏发布目录}/StreamingAssets/…（RevABLoader.cs:447）；
3. 也就是说：不改这个 URL，AB 永远只能来自"发布包自带的那个目录" → 想热更就只能"覆盖发布目录里的同名文件"，那等于放弃原子切换、放弃回滚、放弃"同版本内多次热更"，而且有 CDN/浏览器缓存一致性风险；
4. 所以小游戏的正确做法是：资源放到 CDN，URL 里带版本段（{cdn}/{平台}/{大版本}/{资源版本}/bundles/hero），客户端按清单决定用哪个版本 → "重定向"在这里就是热更的全部；
5. 但反过来，小游戏上不需要：落地目录、.tmp + rename、断点续传、文件级 SHA-256（没有"下载完的文件"可以读回来算哈希）→ 这些在小游戏上是纯负担。

小游戏上的替代形态（都在本文档既有章节里，只是换个实现）：

17.5 抽取出的平台化设计（对前面章节的具体改动）

新增一个只有 两个实现 的小抽象（各约 30 行），把"文件型 / URL 型"分开：

// 下载接收器：文件型落盘、URL 型交给引擎（小游戏）
internal interface IRevHotSink
{
    // 文件型：下载到 .tmp → 校验 → 原子 rename → 版本目录
    // URL 型：不落地，直接返回"该包应使用的最终 URL"（交给框架的 WebGL 分支去加载）
    RevTask<string> PrepareAsync(RevHotBundleInfo bundle, RevHotSource source, RevCancellationToken token);
}
internal sealed class RevHotFileSink : IRevHotSink { ... }    // Android / iOS / PC
internal sealed class RevHotUrlSink  : IRevHotSink { ... }    // WebGL / 小游戏（只拼 URL + 交给引擎校验）

17.6 小游戏专项注意（8 条，全是真金白银的坑）

1. 代码包有体积上限（且平台会调整） —— 所以"AB 全走 CDN"是前提，不是选择；首包只放"能跑起来的最小可玩集"；
2. 没有文件系统 —— 所有"落地 / 断点续传 / 文件校验"换成"引擎缓存 + 引擎校验"，别照搬 Android 那套；
3. CORS 必须配 —— 对象存储/CDN 要放开 GET、Range（引擎可能用）与你们自定义的 Header；配错的表象是"网络错误"，排查极费时间；
4. 缓存策略：内容文件用带版本段的 URL（可长缓存、天然不可变）；清单 URL 必须 no-cache（或带 ?t=）；
5. 并发降到 2、包粒度做小 —— 单线程 + 内存上限，大包会带来内存峰值（这也是"分包粒度"在小游戏上比在手机上更重要的原因）；
6. 平台自己的更新机制管"代码包"，不管"资源" —— 微信 UpdateManager / 分包加载解决的是代码包体积与更新，资源热更仍然是我们这套；
7. 清单里必须带 Unity 的 hash（Hash128）与 CRC —— 引擎的缓存与校验吃的是这个，不是 SHA-256（生成方式见附录 A 的补列说明；实测确认一次）;
8. 首屏要"最小资源集" —— 小游戏首次进入必然要下载，进度条 + 分阶段加载的体验设计比在手机上更关键（这也是第 4 步"首包瘦身 / 按需下载"在小游戏上是刚需而非可选项）。

17.7 回答"有没有必要"（总结）

18存储与 CDN 选型（Android + 小程序）

18.1 一句话选型表

18.2 小程序的硬约束（选谁都躲不过，务必先看这一节）

18.3 Android 侧的约束（宽松得多，但有几条会踩）

18.4 推荐组合与理由（为什么首选腾讯云 COS + CDN）

18.5 云端要配的东西（清单，缺一条都会变成"玄学 bug"）

18.6 成本量级：为什么"差量更新"能直接省出云费

下载量 ≈ 单次更新体积 × 更新次数 × 活跃玩家数

① 不做差量（每次全量 1 GB）：
   1 GB × 1 次/周 × 10 万玩家 ≈ 400 TB/月 → 按 ~0.2 元/GB ≈ 8 万元/月量级
② 做差量（每次更新 50 MB）：
   50 MB × 1 次/周 × 10 万玩家 ≈ 20 TB/月 → ≈ 4 千元/月量级

（单价为国内 CDN 常见的量级参考，实际以官网报价/合同为准；真正的结论是：
  "只下变化的包"这件事本身就是最大的一笔成本优化，而不是把 CDN 换一家。）

18.7 和小游戏平台自带的方案什么关系

18.8 一句话结论

A清单样例全文

# RevHotManifest v1 —— 行式文本，与 ResMap.txt 同族（# 开头是注释，空行忽略）
# 字段：@key|value / @bundle|包名|hash|字节数|依赖(逗号分隔)|标签(逗号分隔)
@appVersion|1.2.0            ← 大版本锚点（= Application.version）；不匹配 → 拒绝更新并引导强更（第十六章）
@resVersion|1.2.0.37         ← 资源版本（同一大版本内自增；玩家看到的就是它）
@minAppVersion|1.2.0         ← 兼容下限（补丁包场景；一般 == @appVersion）
@baseManifest|Baseline.txt   ← 该大版本的基线清单（随包体发布的那份，供差量计算与回滚）
@version|1.2.0-p1            ← 打包工具的版本字符串（给人看，进 BuildManifest.json 的那个）
@platform|Android
@channel|official
@env|prod
@hashAlgo|sha256
@builtAt|2026-10-01 12:00:00
@bundleCount|6
@firstPackageBundles|common,ui_login

# 映射表也要热更（新增资源全靠它）
@resmap|ResMap.txt|3f7a1c9d4b6e8f20a1c2d3e4f5a6b7c8d9e0f1a2b3c4d5e6f708192a3b4c5d6e|20481

# 包：名称|hash|字节|依赖|标签（builtin = 首包内置；hot = 可热更；optional = 按需下载）
@bundle|common|7c1e...|1572864|common|builtin,hot
@bundle|ui_login|9b2f...|1048576|common|builtin,hot
@bundle|ui_bag|1a3d...|2097152|common,ui_login|hot
@bundle|hero|5e6f...|15728640|common|hot
@bundle|effect_battle|8d9c...|8388608|common,hero|hot
@bundle|scene_arena|2b4a...|25165824|common|hot,optional

# ★ 目标平台含 WebGL / 小游戏时，每行末尾再补两列（交给引擎做缓存与校验，见第十七章）：
#    @bundle|名称|sha256|字节|依赖|标签|unityHash|unityCrc
#    unityHash = AssetBundleManifest.GetAssetBundleHash(包名).ToString()
#    unityCrc  = 该包 .manifest 里的 CRC（无签名数字型）
# 例：@bundle|hero|5e6f...|15728640|common|hot|f3a1c2...|3524891730

B一次完整热更的日志长什么样

[HotUpdate] 大版本 1.2.0（Application.version）· 本地资源版本 1.2.0.36（{persistent}/RevHotUpdate/Android/1.2.0/1.2.0.36）
[HotUpdate] 拉取清单：https://cdn.example.com/gameA/prod/Android/1.2.0/official/RevHotManifest.txt?t=1759300000 （18.4 KB，82 ms）
[HotUpdate] 远端：资源版本 1.2.0.37（builtAt 2026-10-01 12:00:00，appVersion 1.2.0 ✓ 与当前包体一致）
[HotUpdate] 差量（对比基线 Baseline.txt）：新增 1、变更 2、删除 0、映射表 有更新 → 需下载 17.8 MB（3 个文件）
[HotUpdate] 下载 1/3 ui_bag 2.0 MB ✓（sha256 校验通过，412 ms，4.9 MB/s）
[HotUpdate] 下载 2/3 hero 15.0 MB ✓（sha256 校验通过，3.1 s，4.8 MB/s）
[HotUpdate] 下载 3/3 ResMap.txt 20.0 KB ✓
[HotUpdate] 写入版本目录 1.2.0.37 → 打完成标记 .stamp → 切换 current.txt（原子替换）
[HotUpdate] 清理旧版本：删除 1.2.0.35（同一大版本内保留 2 份）
[HotUpdate] 装钩子：BundlePathResolver = RevHotStore.ResolveBundlePath（根注入），ResMapOverride = RevHotStore.BuildResMap
[HotUpdate] 重装资源策略（RevResBootstrap.Init）→ 就绪，总计 3.9 s

# 小游戏（WebGL / URL 型平台）同一次更新长这样 —— 没有落地、没有续传，缓存与校验交给引擎：
[HotUpdate] 大版本 1.2.0 · URL 型平台：资源直接走 CDN（不落地），版本段 1.2.0.37
[HotUpdate] 资源根：https://cdn.example.com/gameA/prod/WebGL/1.2.0/official/bundles/
[HotUpdate] 差量（对比内置基线）：变更 2、映射表 有更新 → 需加载 17.0 MB（引擎缓存命中 0）
[HotUpdate] hero 15.0 MB → 17.0 MB 已由引擎缓存/校验完成（hash + crc 均已下发）→ 总计 6.2 s

C实施顺序建议（最不容易返工的顺序）

① 先定清单格式与解析（它同时决定编辑器工具与运行时的接口）—— 写完就跑工程外断言
② 再定盘上布局（版本目录 / tmp / current / 原子提交）—— 这是"能不能续传/回滚"的地基
③ 然后写下载器（先单文件跑通，再加并发/重试/多源/续传）
④ 最后接框架钩子（此时"文件已经到位"，钩子只是把路径指过去 —— 最不容易出问题）
⑤ 编辑器工具放在 ④ 之后（此时清单格式已经冻结，工具只是"填数据"）

对应代码版本：框架 Assets/Revolution/Runtime/RevResourceSystem/（RevABLoader.cs / RevResBootstrap.cs / RevResManager.cs / RevABResPolicy.cs）+ 打包工具 Assets/Revolution/Editor/RevResourceSystem/ABTool/；RevHotUpdate 已实现（Assets/Revolution.HotUpdate/，运行时 18 个文件 / 3309 行 + 编辑器 2 个文件 / 427 行）。本文档保留"方案阶段"的完整论证（含现状盘点里的 ❌ 标记与钩子草案），实现后的落地情况与差异见《RevHotUpdate 架构解析》第七、九章。