1. 热更新安全排查的整体思路与方案选型做过 Unity 手游的同行都清楚热更新是绕不开的一环。资源包从打包、上传 CDN、下发清单到客户端下载、校验、落盘、加载这条链路里任何一个环节出问题轻则玩家卡在登录界面重则资源被篡改、缓存被污染甚至出现“同一版本不同玩家表现不一致”的诡异现象。我这次要聊的就是围绕Unity AssetBundle 热更新这条链路做一次系统性的安全排查重点落在CDN 清单和本地缓存这两个最容易被忽视、却最容易出事的节点上。先说清楚这套东西是什么、能解决什么问题。AssetBundle 热更新本质上是把游戏资源贴图、预制体、音频、配置表、甚至部分代码程序集打成一个个独立的包运行时按需从远端拉取。CDN 负责把这些包和一份“清单文件”分发到离玩家最近的节点客户端拿到清单后决定下哪些包、下完存哪里、下次怎么复用。安全排查要做的就是确认这条链路上清单有没有被篡改的可能、下载的包和清单是否一致、本地缓存会不会被旧数据污染、断点续传和版本切换时会不会读到脏数据。适合谁来参考如果你正在负责 Unity 项目的资源热更模块或者你是个独立开发者用 CDN 分发自己的小游戏资源再或者你是刚接手一个老项目、发现热更逻辑一团乱麻需要梳理这篇内容都能直接拿去对照。我不打算只讲概念而是把每一步的“为什么这么设计”“参数怎么算”“坑在哪”都摊开说尽量让你看完就能动手排查自己项目里的同类问题。在方案选型上我倾向于把排查分成三层清单层、传输层、缓存层。清单层关注的是版本号、哈希、依赖关系是否可信传输层关注 CDN 回源、缓存头、断点续传的正确性缓存层关注本地文件命名、校验、清理策略。这三层不是孤立的很多线上事故恰恰是层与层之间的衔接没做好比如清单更新了但 CDN 缓存没刷新或者本地缓存用文件名做 key 导致新旧包互相覆盖。下面我会逐层拆开讲。提示安全排查不是一次性动作建议把它做成一个可重复执行的检查清单每次发版前跑一遍比出事后再救火划算得多。2. 清单层CDN 上的清单文件到底可不可信2.1 清单文件的结构与常见字段解读AssetBundle 的清单通常有两种形态一种是 Unity 自带的 manifest比如 AssetBundleManifest另一种是项目自己维护的版本清单JSON 或二进制。实际项目里为了灵活控制大多数团队会自己生成一份 JSON 清单里面至少包含这些字段资源包名、版本号、文件大小、MD5 或 SHA256、依赖列表、是否强制更新。我见过不少项目只写了包名和版本号哈希字段直接留空这就等于把校验的大门敞开了。清单里最关键的其实是哈希值和版本号的组合。版本号决定“要不要更新”哈希值决定“下下来的东西对不对”。如果只有版本号没有哈希客户端就无法判断 CDN 返回的内容是不是被中间环节替换过如果只有哈希没有版本号每次启动都要全量比对流量和耗时都受不了。合理的做法是版本号做粗粒度判断哈希做细粒度校验两者配合。还有一个容易被忽略的字段是依赖列表。AssetBundle 之间是有依赖关系的比如一个 UI 预制体依赖某个图集包。如果清单里依赖写错了客户端可能只下了主包没下依赖包运行时直接报 missing 错误。排查时要重点看依赖是不是双向一致——A 说依赖 BB 的引用计数里也应该能对上。2.2 清单被篡改的几种典型路径与防护清单从服务器生成到玩家手里中间要经过构建机、对象存储、CDN 回源、边缘节点。任何一个环节被污染玩家拿到的清单就可能是错的。常见的风险路径有这么几条构建脚本生成的清单没有签名上传后被误覆盖CDN 缓存了旧清单新版本发布后部分节点还在返回老数据清单里的下载地址是明文 HTTP被中间人替换。防护手段我一般推荐三层。第一层是清单签名用非对称加密对清单内容做签名客户端内置公钥验签这样即使清单被替换验签也过不了。第二层是CDN 缓存策略清单文件必须设置较短的缓存时间或者用带版本号的路径比如 /manifest/v1.2.3/manifest.json避免边缘节点缓存旧文件。第三层是HTTPS 全链路这个不用多说明文传输在现在这个环境下基本等于裸奔。这里有个实操细节很多团队把清单和资源包放在同一个目录、用同一套缓存规则这是不对的。资源包内容不变时可以长期缓存清单必须频繁刷新。我通常会把清单单独放一个路径缓存头设成Cache-Control: no-cache或者很短的 max-age资源包则设成max-age31536000配合文件名带哈希。2.3 版本号设计别让“版本回退”变成灾难版本号设计看着简单其实坑很多。我见过用时间戳做版本号的结果服务器时间回拨导致客户端认为“没有新版本”也见过用自增整数的多分支并行开发时版本号冲突。比较稳妥的做法是用语义化版本 构建号比如 1.2.3.456前三位是策划可读的版本最后一位是每次构建自增。客户端比较时按位比较避免字符串比较带来的“10 比 9 小”这种低级错误。更关键的是版本回退场景。线上出问题需要回滚到旧版本时如果客户端只认“版本号更大就更新”那回退就失效了。解决办法是在清单里加一个强制版本标记或者回退指令客户端看到这个标记就无条件切换到指定版本而不是单纯比大小。这个字段一定要在排查时确认存在否则真到回滚那天会手忙脚乱。注意版本号比较一定要用数值比较或按段比较绝对不要直接拿字符串比大小。我踩过这个坑1.10.0 被判定成小于 1.9.0导致更新逻辑整个错乱。3. 传输层CDN 分发与下载校验的实操要点3.1 CDN 缓存头与回源策略的排查方法CDN 这一层最典型的问题就是“我明明传了新包为什么玩家还是下到旧的”。十有八九是缓存头没设对或者回源策略有问题。排查时我会先用命令行工具直接请求 CDN 节点看返回的响应头里Age、Cache-Control、ETag这几个字段。Age很大说明命中了边缘缓存如果这时候内容还是旧的那就是缓存没刷新。资源包的缓存策略我一般这么设文件名里带内容哈希比如ui_login_ab8f3c.bundle这样内容一变文件名就变天然不会命中旧缓存可以放心设长缓存。清单文件则相反路径固定但内容常变必须短缓存或者不缓存。有些团队为了省事资源包也用固定文件名那就只能靠手动刷新 CDN运维成本极高不推荐。回源策略方面要确认 CDN 在缓存未命中时是回源到对象存储还是回源到构建机。如果回源到构建机而构建机上的文件已经被下一次构建覆盖了那玩家可能下到“半新半旧”的包。正确做法是每次构建产物上传到对象存储后就不再改动CDN 只回源到对象存储的不可变路径。3.2 下载校验哈希比对与断点续传的正确姿势下载环节的校验核心就一句话下完必须比对哈希比对不通过必须丢弃重下。我见过一些项目为了“提升体验”下载完直接落盘校验放到加载时做结果就是脏包进了缓存后面每次加载都失败玩家只能清数据。正确的顺序是下载到临时文件 → 计算哈希 → 与清单比对 → 通过才移动到正式缓存目录。断点续传也是个重灾区。HTTP 的 Range 请求本身没问题问题在于很多项目在续传时没有校验已下载部分的完整性。比如第一次下了 50%第二次续传时服务器上的文件已经变了虽然概率低但确实会发生拼起来就是个坏包。稳妥的做法是续传前先比对已下载部分的哈希或者用 ETag 做一致性判断不一致就从头下。下面这段伪代码展示了下载校验的核心逻辑实际项目里可以根据自己的网络库调整// 下载并校验单个 AssetBundle IEnumerator DownloadAndVerify(string url, string expectedHash, string savePath) { string tempPath savePath .tmp; using (UnityWebRequest req UnityWebRequest.Get(url)) { req.downloadHandler new DownloadHandlerFile(tempPath); yield return req.SendWebRequest(); if (req.result ! UnityWebRequest.Result.Success) { // 网络失败记录并重试 yield break; } } // 计算临时文件哈希 string actualHash ComputeFileHash(tempPath); if (actualHash ! expectedHash) { // 哈希不匹配删除临时文件触发重下 File.Delete(tempPath); yield break; } // 校验通过原子移动到正式路径 if (File.Exists(savePath)) File.Delete(savePath); File.Move(tempPath, savePath); }这段逻辑里有两个细节值得强调。一是用临时文件加原子移动避免下载中途崩溃留下半个文件被当成完整缓存。二是哈希计算要放在下载完成后立即做不要拖到加载时早发现早重试。3.3 并发下载与超时重试的参数选择并发数不是越大越好。我实测下来移动端同时开 4 到 6 个下载连接比较合适再多会因为带宽争抢和系统限制导致单个连接变慢整体耗时反而上升。超时时间建议设成 15 到 30 秒太短容易在弱网下误判失败太长会让玩家干等。重试次数一般 2 到 3 次并且要做退避比如第一次失败等 1 秒第二次等 3 秒避免雪崩式重试把 CDN 打挂。还有一个容易被忽略的点是下载优先级。登录界面需要的资源应该优先下进游戏后才用到的可以延后。如果所有包一视同仁地并发下载玩家可能卡在登录界面等一个根本用不上的场景包。排查时要确认下载队列有没有按优先级排序。4. 缓存层本地存储的命名、校验与清理策略4.1 缓存目录结构与文件命名规范本地缓存最容易出的问题是“新旧包混在一起加载时读错”。根源往往在命名上。如果缓存文件名只用资源包名比如ui_login.bundle那新版本覆盖旧版本时如果覆盖过程中断就会留下一个损坏的文件。正确做法是文件名里带上版本或哈希比如ui_login_ab8f3c.bundle新版本是另一个文件名旧文件可以安全地留着或延后清理。目录结构我一般按“平台 版本”分层比如Cache/Android/1.2.3/。这样切换版本时直接换目录旧版本目录整体删除即可不会出现跨版本污染。有些项目把所有版本的文件堆在一个目录里靠文件名区分时间一长目录里几千个文件清理逻辑稍微写错就误删。还有一点是缓存路径的可写性。在部分平台上应用安装目录是不可写的缓存必须放在持久化数据目录。排查时要确认代码里用的是正确的路径 API而不是硬编码的路径字符串。4.2 缓存校验启动时该查什么、不该查什么启动时全量校验所有缓存文件的哈希这个做法听起来很安全实际上很蠢。玩家手机里可能存了几个 G 的资源每次启动都算一遍哈希耗时几十秒体验直接崩了。合理的策略是分级校验清单文件每次启动都校验因为它是入口资源包只在首次下载后校验一次之后靠“版本目录隔离”来保证正确性不做重复校验。如果确实担心缓存被外部篡改比如玩家手动改文件可以在加载单个包时做一次轻量校验比如只校验文件大小和头部几个字节而不是全文件哈希。全文件哈希只在下载完成时做一次就够了。这里有个经验校验失败的包不要直接删先移到隔离目录并上报。这样既能保证游戏正常运行又能收集到哪些包容易出问题方便后续分析。直接删掉的话问题现场就没了。4.3 缓存清理什么时候清、清多少、怎么清不误伤缓存清理的触发时机一般有三个版本更新后清理旧版本、磁盘空间不足时清理、玩家手动清理。版本更新后的清理最简单直接删掉旧版本目录。磁盘不足时的清理要小心不能把当前版本正在用的包删了。我的做法是给当前版本目录加一个“使用中”标记清理时跳过这个目录。清理策略上我倾向于按最近使用时间LRU而不是按大小一刀切。记录每个包最后一次加载的时间空间不足时从最久没用的开始删。这样既释放了空间又不会影响玩家当前正在玩的进度。提示清理操作一定要在后台线程做并且加锁保护避免和正在进行的下载或加载冲突。我见过清理线程把正在下载的临时文件删了导致下载永远完不成。5. 常见问题与排查技巧实录5.1 典型故障速查表下面这张表是我这些年遇到的热更相关问题里最高频的几类按现象、可能原因、排查手段整理方便你对照使用。现象可能原因排查手段玩家卡在更新界面不动清单请求失败或超时抓包看清单请求返回码检查 CDN 是否可达更新后部分资源显示异常缓存里新旧包混用检查缓存目录是否按版本隔离文件名是否带哈希同一版本不同玩家表现不一致CDN 节点缓存不一致多节点请求同一资源比对返回内容哈希下载完成但加载报错下载校验缺失脏包落盘检查下载后是否比对哈希临时文件是否原子移动版本回退后玩家仍是新版本客户端只比版本号大小检查是否有强制版本标记字段弱网下更新极慢并发数过高或超时过短调整并发到 4-6超时到 15-30 秒加重试退避缓存目录越来越大旧版本未清理检查版本切换时是否删除旧目录5.2 独家避坑技巧第一个技巧是给清单加一个“构建时间戳”字段。排查线上问题时只要让玩家截个图或者上报这个字段就能立刻知道他用的是哪次构建的清单省去大量猜测。这个字段不参与逻辑判断纯粹用于排查成本极低但价值很高。第二个技巧是在下载 URL 里带上版本参数。比如?v1.2.3这样即使 CDN 缓存策略没设好不同版本的请求 URL 不同也能天然避开旧缓存。这个做法对清单和资源包都适用算是缓存策略之外的一道保险。第三个技巧是本地缓存目录里放一个“版本指纹”文件。记录当前缓存的版本号、清单哈希、写入时间。启动时先读这个文件如果和远端清单对不上就知道需要更新。这个文件很小读写极快比每次扫描整个目录高效得多。5.3 排查工具与命令速查排查 CDN 和缓存问题命令行工具比图形界面快得多。我常用的几个# 查看 CDN 响应头重点看 Cache-Control、Age、ETag curl -I https://your-cdn.com/manifest/v1.2.3/manifest.json # 下载文件并计算哈希和清单比对 curl -o test.bundle https://your-cdn.com/bundles/ui_login_ab8f3c.bundle sha256sum test.bundle # 强制不走缓存请求验证源站内容 curl -H Cache-Control: no-cache -I https://your-cdn.com/manifest.json在客户端侧我会在开发包里加一个调试面板能实时显示当前缓存版本、已下载包数量、缓存占用空间、最近一次校验结果。这个面板在排查玩家反馈时特别有用让玩家截个图就能定位问题。6. 把安全排查做成常态化机制聊了这么多具体的技术点最后说点偏流程的东西。热更新安全排查如果只在出事时做那永远是被动的。我的做法是把它拆成几个固定动作嵌到发版流程里。构建阶段自动生成清单并签名上传阶段校验 CDN 缓存头是否符合预期发版后用一个自动化脚本模拟客户端走一遍完整下载校验流程确认线上清单和资源包都能正确拉取和校验。这套机制跑顺了之后大部分低级问题在发版前就能拦住。剩下的就是一些环境相关的偶发问题靠客户端上报的日志和版本指纹来定位。说实话热更新这块没有一劳永逸的方案CDN 环境、玩家网络、设备差异都会带来新的变量保持排查意识、把关键校验做扎实比追求某个“完美方案”更实际。我个人在实际操作中的体会是清单和缓存这两块最值得投入精力因为它们一个是入口、一个是落脚点中间传输环节反而相对标准化。把清单的签名和版本设计做对把缓存的命名和校验做对热更新这条链路就稳了大半。剩下的并发、重试、清理这些都是在这个基础上做优化优先级可以往后放。