自动关联目录：热更新与补丁

热更新的前提是"资源可以覆盖，代码不可以"。UE 的 pak 挂载机制天然支持资源覆盖，所以热更的对象是资产与配置；C++ 逻辑要改，只能换包（或用 Lua 这类脚本层）。

一句话定位：热更新 = 下载更高优先级的 pak → 校验 → 挂载。技术难度不高，难的是版本管理与失败处理。

能力边界

设计约束：任何"可能会被热更需要改动"的逻辑，一开始就该放在脚本层或数据层。把逻辑写死在 C++ 里，等于放弃热更能力。

完整流程

① 启动 → 读本地版本清单（version.txt / manifest）
② 请求服务器版本 → 比对
③ 有更新 → 下载（全量 pak 或 差分补丁）
④ 校验（文件大小 + 哈希 + 可选签名）
⑤ 写入持久目录（原子写：先 .tmp，再 rename）
⑥ 更新本地版本清单（这一步必须在挂载之前持久化完成）
⑦ Mount pak
⑧ 进入游戏

第 ⑥ 步是本流程中唯一必须"先落盘再生效"的地方。如果先挂载再写清单，中途崩溃会导致"代码以为已更新、磁盘上还是旧的"，也就是所谓"半更新状态"。

版本管理

PersistentDir/
  Paks/
    patch_v120.pak
    patch_v121.pak
    patch_v122.pak     ← 挂载时按版本号倒序，新的优先
  version.txt          ← 已生效的版本

差分补丁的隐患：补丁链越长，中间任一环出错就越难恢复。常见做法是超过 N 个补丁就要求下载全量包。

差分方案

按资产粒度做差分往往比二进制差分更实用：pak 里资产顺序一变，二进制差分就失效；而按资产对比能稳定识别出"只有这 3 个贴图变了"。

校验

// 写入前校验哈希，不匹配就删掉重新下
FString Hash = FMD5::HashFile(*TmpPath);
if (Hash != ExpectedHash) { IFileManager::Get().Delete(*TmpPath); return false; }
IFileManager::Get().Move(*FinalPath, *TmpPath);   // 原子替换

永远不要直接下载到目标文件名——中断会产生半截文件，下一次启动会把它当成有效文件。

失败与回滚

最重要的兜底：让"更新失败"不等于"进不去游戏"。强更（不更新不能玩）要有单独的理由与提示，不要默认开启。

// 崩溃保护：用本地计数值判断
int32 CrashCount = LoadCrashCount();
if (CrashCount >= 3) { SkipMountedPatches(); }   // 安全模式

强制更新与兼容性

判断标准：旧版本客户端继续运行会不会造成数据污染或破坏他人体验。会 → 强更；不会 → 允许延迟更新。

移动端额外事项

iOS 上热更脚本引擎是有审核风险的，Lua 相对安全，但下发 .lua 源码/字节码仍可能触发审核问题——上线前必须确认当时的审核口径。

监控

没有监控的热更新等于盲飞。至少要有"更新后 24 小时崩溃率"这一条。

常见坑