干 Unity 热更的兄弟估计都遇到过这种情况游戏发版后玩家群里开始有人反馈更新下载完就闪退资源加载不出来你排查了 CDN 配置、查了 AssetBundle 打包流程、确认了版本号最后发现是客户端本地缓存里残留了一份旧清单加载逻辑还优先读取了它。更要命的是有些更新包异常根本不是网络问题而是 CDN 到本地这一路的安全校验存在漏洞——清单被串改、哈希被绕过、缓存文件被替换任何一个环节失守热更就变成了一场事故。这篇内容不跟你聊大而全的框架设计专门围绕Unity AssetBundle 热更新安全排查从 CDN 清单到本地缓存把这条链路拆开揉碎讲清楚风险到底出在哪、怎么定位、怎么加固。适合正在做热更系统、被线上资源问题反复折磨的 Unity 客户端开发者也适合后端同学了解 CDN 与端侧协同校验的逻辑。1. 一条热更请求走完整链路后安全风险藏在哪三个环节1.1 常规热更流程里清单扮演的角色AssetsBundle 热更新的常规做法是客户端启动时先请求一个版本清单文件里面记录了当前热更版本号、每个 AssetBundle 的文件名、MD5/CRC 哈希、下载地址或者相对路径。客户端解析清单后和本地已有的资源清单做对比找出需要新增、更新、删除的 Bundle再逐个下载。这个清单文件在工程里有各种叫法常见的是version.json、filelist.json、assetbundlemanifestUnity 官方打包时也会生成一个.manifest文件。无论叫什么它的本质都是一张资源档案表告诉客户端服务器端当前有哪些资源、每个资源的指纹是什么。很多人觉得清单只是个对比用的配置文件安全意义不大。这个认知是错的。清单一旦被篡改后面所有的哈希校验、版本判断都会建立在错误的前提上。攻击者只需要把清单里的hash字段替换成恶意包的哈希再把你引导到恶意 CDN 地址客户端就会老老实实下载并加载被篡改的 AssetBundle。所以排查热更安全问题第一步永远是审视清单的获取与校验链路。1.2 本地缓存不是你想的存个文件那么简单AssetBundle 下载完成后客户端需要把文件持久化到本地避免每次启动都重新下载。这里的本地缓存至少有三层概念Unity 自带 Caching APIUnityWebRequestAssetBundle配合Caching.AddCache等方式会把下载的 AB 存到 Unity 管理的缓存目录中并自动关联版本号。自建缓存目录很多团队为了可控性不用 Unity 的 Caching而是自己把 AB 文件写入Application.persistentDataPath下的某个目录通过自定义清单记录哪些文件已经存在。系统级缓存某些平台上CDN 响应本身可能被系统级 HTTP 缓存拦截尤其是 WebGL 平台上的浏览器缓存、Android 的 OkHttp 缓存。排查时必须先搞清楚你用的到底是哪一层缓存每一层的命中逻辑和校验时机都不同。我自己接手过的一个项目就是UnityWebRequest 自建缓存目录混用热点文件用Caching缓存、普通文件手动落盘结果两边各存了一份差异版本排查时差点怀疑人生。1.3 三环节风险地图CDN 下发、清单解析、缓存落盘把热更链路摊开看安全风险的集中点无非三个大环节环节风险类型表现CDN 下发清单与 AB 文件中间人篡改、CDN 源站被入侵、缓存配置错误导致旧文件拿到错误的清单或损坏的 Bundle客户端清单解析校验缺失、弱校验、解析器容忍异常字段用错误的哈希对照、遗漏文件、接受伪造版本号本地缓存落盘与读取缓存被替换、残留旧文件、多版本混放加载到旧资源或恶意替换资源后面几个部分我会沿着这三个环节逐个展开并给出具体的排查命令、代码片段和加固配置。2. 清单校验的几层防线版本号、Hash、CRC 和签名2.1 版本号比对整数代差为什么挡不住回滚攻击最朴素的清单校验就是版本号。服务器返回{version: 1001, files: [...]}客户端对比当前版本如果服务器版本更高就增量更新。这个逻辑够用吗只能防手滑发错包防不了恶意回滚。举个例子攻击者抓包拿到你历史版本 1000 的清单文件修改代理返回给客户端。客户端的漏洞比较逻辑是服务器版本 本地版本才更新如果本地版本正好是 999那么回滚到 1000 反而会被当成正常更新。更隐蔽的做法是攻击者把清单里的版本号改成 99999客户端以为有大更新把一堆无效地址和错误哈希拉下来轻则资源下载失败重则逻辑被诱导加载异常包。所以版本号比对只能作为更新决策的依据不能作为安全校验的依据。我见过不少项目只判断serverVersion localVersion完全没有对版本号本身做合法性约束。合理的做法有两层客户端内置或预置一个最低可信版本号作为红线低于该值一律拒绝版本号字段参与整体鉴权而不是单独信任。// 错误的版本比对姿势 if (remoteVersion localVersion) { DoUpdate(); } // 带红线和完整校验的姿势 const int MIN_TRUST_VERSION 1000; if (remote.BlockVersion MIN_TRUST_VERSION) { Reject(version too low); } if (!VerifyManifestSignature(remote)) { Reject(manifest invalid); } if (remote.Version localVersion) { DoUpdate(); }2.2 Hash 校验UnityWebRequest 到底帮你做了什么Unity 的UnityWebRequestAssetBundle有个Hash参数。很多人以为传了Hash就完成了校验其实要看代码路径。var uwr UnityWebRequestAssetBundle.GetAssetBundle(url, Hash128.Parse(remoteHash), 0); yield return uwr.SendWebRequest(); var ab DownloadHandlerAssetBundle.GetContent(uwr);这里的Hash主要作用于Unity Caching 系统它生成本地缓存的键并参与缓存有效期判断。也就是说它更偏向于缓存索引而不是严格意义上的完整性校验。你传入的hash怎么来的如果它来自未签名、可被篡改的清单那么攻击者连哈希字段一起替换这个校验就形同虚设。真正可靠的完整性校验应该用Hash128.Parse(remoteHash)只是起点。在下载完成后需要独立地对最终文件内容计算摘要比如把文件读出来跑一遍 MD5 或 SHA256再与与清单独立的可信摘要比对。注意独立可信来源这几个字如果摘要本身和清单一起被篡改那比对就毫无意义。所以摘要要么来自签名校验后的清单字段要么来自内置在客户端里的公钥验签结果。2.3 CRC 与自定义摘要双保险的取舍有些团队在打包阶段会额外生成每个 Bundle 的 CRC 值打包进一个由单独渠道下发的配置表中。客户端下载完文件后跑一遍 CRC32校验失败就重下或上报。CRC32 的优点是快、实现简单适合做传输损坏检测缺点是抗恶意篡改能力弱攻击者可以轻易构造碰撞数据。如果你的威胁模型只是用户网络差、文件传输出错CRC 就够用。如果威胁模型包含有人恶意替换资源文件CRC 不够必须上 SHA256 级别的强摘要并且配合签名机制。实操中我建议这样组合传输过程依赖 HTTPS CDN 完整性头如阿里云的 Content-MD5、S3 的 ETag做第一层保护端侧下载后用 SHA256 对文件做独立校验防止 CDN 边缘节点返回损坏或串改内容校验指纹来源从签名验证通过的清单中读取而不是从裸 JSON 中读取。public static bool VerifyFileSHA256(string filePath, string expectedHash) { using var stream File.OpenRead(filePath); using var sha SHA256.Create(); var hash sha.ComputeHash(stream); var sb new StringBuilder(); foreach (var b in hash) sb.Append(b.ToString(x2)); return sb.ToString().Equals(expectedHash, StringComparison.OrdinalIgnoreCase); }2.4 清单签名端侧验签的工程化姿势真正能挡住清单被篡改这一刀的手段是对清单文件本身做签名。做法是服务器端用私钥对清单内容版本号 文件列表 摘要等做签名客户端内置公钥在解析任何字段之前先验签。这里有一个工程化细节公钥不能直接硬编码在代码里且不做任何保护。Unity 打包后的 IL2CPP 代码虽然比 Mono 难逆向但公钥仍然可能被提取替换。更稳妥的做法是把公钥或公钥哈希再做一次白名单校验或者分片存放在不同位置关键项目的做法还可以配合加固服务。当然绝大多数项目到内置公钥 RSA 验签这一层就已能拦截 99% 的脚本攻击者。验签代码要放在解析逻辑的最前端并且要覆盖清单所有字段包括版本号、文件路径、哈希值。有些项目只签了哈希列表版本号裸奔攻击者仍然可以回滚版本号来干扰更新逻辑。public static bool VerifyManifest(byte[] manifestData, byte[] signature, string publicKeyPem) { using var rsa RSA.Create(); rsa.ImportFromPem(publicKeyPem); return rsa.VerifyData(manifestData, signature, HashAlgorithmName.SHA256, RSASignaturePadding.Pkcs1); }3. 本地缓存排查从 Caching API 到自建缓存目录3.1 Unity Caching 的默认行为版本、路径、失效Unity 的 Caching 系统行为有几个关键点排查本地缓存问题时必须清楚缓存路径由 Unity 管理Application.persistentDataPath或 Unity 内部目录不同平台不一样Caching.IsVersionCached(url, hash)可以判断某资源是否已缓存同一个 URL 配合不同Hash128会被视为不同的缓存条目如果缓存空间不足Unity 可能淘汰旧缓存在 Android 上缓存目录可能被系统清理尤其是在应用被卸载重装后。常见误区是以为Hash128传错或没传只会影响缓存命中不会有严重后果。实际上如果清单里哈希来自一个被篡改的字段Unity 会用这个哈希建立索引后续版本更新时可能因为哈希不匹配无限重下或者因为哈希碰撞误加载到错误缓存。排查 Caching 问题时可以用下面的方式确认当前缓存状态var hash Hash128.Parse(remoteHash); Debug.Log($Cached? {Caching.IsVersionCached(uri, hash)}); foreach (var cache in Caching.GetAllCachePaths()) { Debug.Log($cache path: {cache}); }3.2 自定义缓存目录为什么很多人放弃了 Caching API说实话Unity 自带 Caching 在早年版本表现不太稳定跨平台目录不可控、清理策略黑盒、部分平台尤其 WebGL行为差异大所以很多项目选择自建缓存目录。自建缓存目录的核心是自己管理两件事文件存储结构通常是persistentDataPath /bundles/ version / bundleName本地清单记录已下载文件的名称、大小、哈希、下载时间。自建缓存最常见的坑是本地清单和实际文件不一致。比如下载写了一半进程被杀文件损坏但清单里已经标记完成或者用户清理了文件目录但本地清单还残留记录又或者多版本混合更新时新版本的 Bundle 下载成功旧版本文件没有被及时清理导致同名 Bundle 被加载成旧资源。我建议自定义缓存目录一定要做三步校验启动时扫描目录文件列表与本地清单比对多出的文件清理、缺失的文件重新下载每次加载 AssetBundle 前先比对本地记录的文件哈希与实际文件哈希不一致则删除重下写入文件时采用临时文件 原子改名的方式避免写一半崩溃留下半截文件。string tmpPath filePath .tmp; File.WriteAllBytes(tmpPath, data); if (VerifyFileSHA256(tmpPath, expectedHash)) { File.Move(tmpPath, filePath, true); // 原子替换 } else { File.Delete(tmpPath); // 标记失败进入重试 }3.3 缓存残留与命名冲突加载到旧资源的常见原因做热更排查时我最常遇到的一类问题是服务器清单明明是新版本下载也成功但加载出的资源还是旧的。第一反应怀疑 AssetBundle 加载接口但根因往往在缓存目录。举一个典型场景项目早期用 Bundle 名做文件名直接存缓存目录比如role_avatar。后来某次打包同一个 Bundle 的内容发生了结构性变化但文件名没变。客户端增量更新时清单认为该文件名需要更新下载了新文件但如果你用的是AssetBundle.LoadFromFile(path)而 path 指向的是缓存目录那就应该加载到新文件。问题出在有些团队用AssetBundle.LoadFromFile(Application.streamingAssetsPath / name)加载原始包资源没有切换到更新后的缓存路径——旧文件一直躺在安装包内没有被覆盖。另一种常见情况是多进程或多线程同时写缓存。Unity 手游在进入战斗场景时会预下载资源如果同一个 Bundle 有两个下载任务并发执行后写完成的文件可能覆盖先写完成的但哈希校验的顺序和写入顺序不一致就会造成文件内容是 A 版本、本地清单记录的是 B 版本的错位。这种问题在低端 Android 机上更容易出现因为文件写入慢、线程调度不稳定。3.4 平台差异Android 与 iOS 缓存目录权限的坑聊本地缓存离不开平台的差异这里专门提醒几个我实际踩过的权限坑Android 公有目录 vs 应用私有目录Application.persistentDataPath在 Android 上通常是/storage/emulated/0/Android/data/{packageName}/files。应用卸载后目录会被清理但在某些国产 ROM 上这个目录可能被清理 App误删。如果你在代码里用Environment.ExternalStorageDirectory拼接路径会拿到公有目录Android 11 以上的分区存储还需要额外适配读写权限更麻烦。iOS 的备份与缓存策略Application.persistentDataPath在 iOS 上对应Documents目录会被 iCloud 备份而Application.temporaryCachePath对应Caches目录不备份但会被系统清理。热更缓存文件如果放在Documents超大 Bundle 会让 App 包体备份膨胀审核时有风险如果放在Caches可能被系统在存储紧张时清空导致下次启动大量重下。只读文件系统某些平台如 WebGL根本没有真正的本地持久化大文件能力IndexedDB 的大小和清理策略不完全受你控制做热更缓存时要有独立的配额判断。4. 复盘一次真实事故清单校验通过、文件下载完成、加载却异常4.1 事故现象和第一轮排查去年我参与维护的一个上线项目玩家反馈在弱网环境下更新后频繁出现资源贴图缺失 特定关卡崩溃。后台查看下载成功率 99% 以上CDN 请求成功率正常第一轮排查根本没头绪。我们做了三件事在崩溃上报里加入了AssetBundle加载路径、清单版本号、本地缓存哈希等字段在下载完成后增加了一行日志输出服务器哈希与实际文件哈希的比对结果让出问题玩家上传了本地的缓存目录结构。结果发现崩溃集中在同一个 Bundle 上而且这个 Bundle 的服务器哈希和本地文件哈希完全对不上。但奇怪的是下载成功日志里记录的比对结果是一致的。4.2 用抓包和本地比对定位根因排查到这里我们怀疑是日志撒谎于是抓了线上玩家的下载流量。抓包发现客户端确实从 CDN 拿到了正确的文件但紧接着有一段时间网络抖动某个请求重试后返回了 206 Partial Content。我们的下载逻辑用的是UnityWebRequest直接下载整个文件照理说不应该出现 206。问题出在 CDN 侧开启了断点续传客户端的缓存库我们用的第三方 HTTP 库也支持断点续传两者配合下一个文件被分两段下载第二段写入的 offset 出现了偏差——文件拼接后长度正确但中间一段内容错位。更隐蔽的是我们下载完成后计算的 SHA256 和服务器哈希是一致的因为计算的是拼接后的错位文件而服务器哈希对应的其实是完整的正确文件。这怎么可能我们再深入打印了分块偏移和实际写入大小才发现某次重试请求的Range头被重复添加导致下载段重复覆盖了同一区域文件长度不变、内容却错位了哈希自然对不上。日志显示一致是因为我们只打了一条总文件哈希一致的结论而那个结论是另一个校验函数错误地取了缓存索引里的哈希没有真正重新读文件。这里给所有做热更的团队一个硬建议下载完成后的完整性校验必须重新打开文件计算绝不能信任下载器内部报告的缓存键或状态。4.3 根因机制与修复方案最终根因锁定在两条CDN 与客户端 HTTP 库的Range重试机制冲突造成断点续传拼接错位客户端校验逻辑存在形式主义漏洞取的是内存中的下载状态而不是落盘文件。修复方案分两层下载层关闭对该 AB 下载请求的断点续传或者在重试时强制重新下载整个文件。我们最终选择弱网重试时丢弃已有断点全量重下代价是少部分慢速用户流量略增但不再出现拼接错位校验层重写校验函数下载完成并落盘后重新打开文件计算 SHA256与清单中的可信摘要比对不一致则删除本地文件、从更新队列重试。// 修复后的下载流程伪代码 IEnumerator DownloadWithVerify(string url, string filePath, string expectedHash) { // 1. 临时文件下载, 不使用断点续传 yield return DownloadToTemp(url, filePath .tmp); // 2. 必须重新打开文件计算哈希 bool ok VerifyFileSHA256(filePath .tmp, expectedHash); if (!ok) { File.Delete(filePath .tmp); // 上报并重试 yield break; } // 3. 原子改名 File.Move(filePath .tmp, filePath, true); }这次事故给我最大的触动是校验逻辑存在不等于校验逻辑有效。排查时要追问每一步校验的数据源到底来自哪里是来自网络响应、内存缓存还是真实文件。5. 热更安全加固清单端侧、服务端、运维侧各管一段5.1 端侧必须做的事基于上面这些经验我整理了端侧热更安全加固时必须覆盖的检查项清单获取走 HTTPS域名做好证书校验有条件的项目可以上证书锁定Certificate Pinning防止中间人替换证书后下发伪造清单。清单验签 字段完整性校验签名覆盖版本号、文件列表、哈希值所有字段不接受部分字段参与签名的偷懒实现。下载完成后重新读文件做强校验不要信任下载器的状态必须File.OpenRead后重新计算 SHA256。加载前二次校验从缓存目录加载 AssetBundle 前比对实际文件哈希哈希不匹配直接重下。这段校验的开销对于 Bundle 文件来说通常可以接受。异常上报把校验失败时的 URL、版本号、期望哈希、实际哈希、缓存路径、平台等关键字段上报到后台方便复现。 注意哈希校验的密钥点不是校验了哈希而是哈希比对双方来自独立可信源。5.2 服务端与 CDN 侧的配合光改客户端不够服务端和 CDN 侧必须同步调整否则有些漏洞封不上CDN 缓存刷新策略更新资源时确保 CDN 上旧版本被主动刷新或配置版本化路径。如果同一个 URL 长期指向旧内容客户端做再多校验也没用推送完整度检测AB 文件上传后由后台任务对全量文件计算哈希并入库发布分支与客户端清单引用同一份指纹避免人工填写哈希出现错误多环境隔离测试环境、预发布环境、生产环境的 CDN 域名和清单地址严格隔离防止测试包连上生产 CDN 或反过来日志与告警对清单请求、AB 下载请求的 4xx/5xx、以及下载后校验失败的行为做告警这类指标突然上升往往意味着攻击或故障。5.3 踩过坑之后的经验纪要最后写几条纯个人经验不一定写在规范文档里但排查时很管用排查顺序固定下来先确认拿到的清单是不是可信 → 再确认下载的文件是不是期望内容 → 最后确认加载的是不是落盘的那份文件。我见过太多人一上来就怀疑AssetBundle.LoadFromFile结果问题出在更上游的清单或下载阶段。复现问题别只看日志抓包和文件级比对永远是最直接的证据。尤其是弱网问题本地回放请求能帮你省掉大量和 CDN 厂商反复拉扯的时间。把缓存视为可丢弃资源而不是可靠资产。缓存损坏后自动重建的路径设计好玩家的损失只是一个加载等待而不是一次闪退。热更安全不是一次性的每次打包流程调整、每次 CDN 切换、每次第三方 HTTP 库升级都应该回测一遍校验链路。我们这次断点续传事故就是一次 HTTP 库升级引入的回归。AssetBundle 热更新做到稳定不难做到安全稳定就需要把清单、下载、落盘、加载每一环都当作独立的信任边界来设计。希望这篇排查复盘能给你自己的热更系统带来一点启发。