Unity热更新安全加固：从AssetBundle清单签名到本地缓存防篡改

做Unity客户端开发的同学应该都有过这样的经历：热更新联调的时候一切正常，一上线上就出幺蛾子——有的玩家更新失败，有的版本回退，有的资源拉下来加载直接崩了，甚至有人把安装包里的资源文件解包出来改了改就能魔改你的游戏逻辑。这篇文章想从一个实际项目的排查过程出发，顺着AssetBundle热更新的链路，把CDN清单、下载校验、本地缓存这三段分别有哪些坑、哪些隐患，以及怎么把这些位置的安全问题一项项填平，说实话讲一遍。

内容不追求理论上的绝对攻防，只讲工程上可落地、可复制、能保护大多数商业项目的实用方案，顺便把排查思路和工具链分享出来，适合正在做Unity热更新或者准备做热更新的朋友参考。

1. 热更新的整体链路与风险地图

1.1 AssetBundle热更新的基本流程

无论你用XAsset、YooAsset还是自己撸轮子，AssetBundle热更新的核心链路都是差不多的：客户端启动后先向CDN请求一份资源清单（Manifest），清单里记录了当前热更版本、所有AssetBundle文件的文件名、大小、MD5或CRC，然后客户端拿这份清单和本地已有资源做对比，找出需要下载的AB文件，逐个从CDN拉取、写入本地缓存，最后再通过AssetBundle.LoadFromFile或LoadFromMemory加载。

听起来并不复杂，但这套流程的每个环节都有安全盲区。我从实际项目里总结下来，最容易被忽略的其实不是资源加密，而是“信任链”的断裂。你的客户端凭什么相信从CDN拉下来的那份清单是真的？又怎么知道下载的AB文件没有被中途替换成恶意版本？本地缓存是否在写完校验之后就不会再被外部篡改？这三个问题不解决，其他所谓的安全策略都是在沙滩上盖楼。

1.2 攻击面分析：CDN、传输链路、客户端本地

我们把热更新的攻击面拆开看，其实就三条线：

第一条是CDN侧。CDN节点理论上是你可控的，但如果你配置了错误回源策略、缓存规则混乱，或者用了公共存储桶不小心把写权限开成公有，任何人都有可能在你CDN上挂木马文件。还有更隐蔽的，如果CDN的鉴权过期时间配得太长，哪怕资源地址被人拿到，也能一直白嫖你的流量和资源文件。

第二条是传输链路，也就是CDN到客户端这段。虽然现在绝大多数项目都上了HTTPS，但中间人攻击并不只是SSL证书的问题。比如你在下载时如果不校验证书链、允许自签名证书、或者直接HTTP明文访问，攻击者完全可以劫持连接，把改过的AB文件返回给你。再比如从CDN拉数据时，如果没做断点续传但做了错误的重试逻辑，重试拿到的文件和之前下载的一半内容混在一起，本身就造成了解压校验失败，这可能被利用来构造特定崩溃。

第三条是客户端本地。文件下载到persistentDataPath之后，如果你的目录权限设置有问题、缓存文件名过于规律、校验逻辑只在下载时做一次而加载时不做二次校验，那玩家或攻击者完全可以直接找到缓存目录，把AB文件替换成他们自己打包的版本，实现所谓“外挂”式修改模型、贴图、甚至技能数值和关卡数据。这在实际商业游戏里真的是最常见的安全事故，反而不是什么高深攻击。

1.3 为什么安全排查必须从“清单”开始而不是从“加密文件”开始

很多团队一上来就搞AssetBundle加密，觉得把AB文件用AES加密一遍就安全了。但加密解决的是“文件内容被直接阅读”的问题，解决不了“文件被整体替换”的问题。你的代码里写死了密钥，别人花一点功夫就能从客户端逆向出来。更关键的漏洞在于清单：如果没有对清单做签名校验，攻击者完全可以自己伪造一份清单，指向他篡改过的AB文件，或者干脆回退到旧版本清单，让你加载被替换的旧资源。

所以我们把排查顺序定为“从CDN清单到本地缓存”是有逻辑的。先保证“信任的源头”是对的，才谈得上后面每一步校验都可信。清单就是整个热更新链路的信任根，这个顺序颠倒，后面做的所有安全策略都白搭。

2. CDN清单的生成、签名与下发验证

2.1 清单里该装什么：版本号、文件列表、Hash与可选签名

先说一个很多项目会犯的错误——清单只保存AB文件名列表和大小。这远远不够。我建议至少包含以下字段：

• 客户端版本号：用于判断客户端是否过老，是否需要强更安装包。
• 资源版本号：热更资源的统一版本，便于做整包版本淘汰。
• 目标平台标识：Android、iOS、Windows、macOS各平台资源不同，不能用同一份清单。
• 文件列表：相对路径、文件大小、MD5或CRC32、可选的文件级版本号。
• 自定义附加信息：比如渠道号、灰度标识、首发公告开关等。

文件列表加Hash这是基础。加文件级版本号主要是为了做增量更新时更灵活，因为如果你只更新了一两个AB文件，没必要让整个资源版本号都变，文件级别上做对比就能省去大量下载流量。

再往下就是可选签名。签名这块的做法不复杂，后面单独说。但值得提醒的是，哪怕你只做内部测试，也建议从第一天就把签名逻辑加进去，否则后来补签名，兼容老客户端的成本会高到你想骂人。

为了直观，我贴一个典型的清单JSON结构，带签名为例：

{ "appVersion": "1.3.2", "resourceVersion": "20240416_001", "platform": "Android", "files": [ { "path": "assets/res/characters/hero_walk.ab", "size": 102400, "md5": "d41d8cd98f00b204e9800998ecf8427e", "version": 1 }, { "path": "assets/res/effects/skill_fire.ab", "size": 20480, "md5": "3f9b1a0b2e6c5d4f7a8b9c0d1e2f3a4b", "version": 3 } ], "signature": "base64..." }

对于小项目，用JSON完全够用；对于大型项目，可以考虑用MessagePack或Protobuf压缩和加密，但签名和校验的原理不变。核心原则是：清单里每一项资源信息都不该是冗余的，而应该是客户端能据此独立完成完整校验的。

2.2 签名算法选型与密钥管理：别把私钥塞进客户端

签名算法上，我现在比较推荐RSA-SHA256，或者更现代的Ed25519。RSA兼容性好、Unity里也容易找到库，Ed25519密钥更短、验证更快、安全性更高，但要在Unity里用的话需要自己引入BouncyCastle之类的库。两者都行，关键是别自己发明签名算法。

签名原理说清楚：在服务器端，你用私钥对清单的“内容部分”做签名，得到一串signature；客户端拿到完整清单后，先用内置的公钥对signature进行验证，如果验证通过，就认为这份清单确实是服务器下发的，未被篡改。

很多人会犯一个致命错误，就是把私钥作为常量写进客户端。私钥一旦泄露，你整个签名机制就形同虚设。私钥应该只存在于服务端构建机或专门的签名服务中，客户端只保存公钥。就算攻击者逆向出公钥，他也无法伪造签名，只能验证签名真伪。

为了让密钥继续安全，你还应该定期更替密钥对，测试环境和生产环境用不同密钥对。一旦发现私钥泄露，要有对应的撤销和紧急更新公钥的流程，虽然客户端更新公钥本身也需要热更，但至少比没有任何补救措施强。

更稳妥的做法是，签名服务做成独立的内部HTTP服务，打包机负责推送待签名的清单内容，服务返回签名。这样私钥连业务服务器都不落盘。当然，对于小团队，一个离线脚本负责签名也够用，关键是私钥必须放在构建环境之外的地方，比如专用的签名机、离线电脑。

2.3 客户端验证流程：从下载清单到信任根建立

客户端拿到清单后，验证流程我建议按顺序怎么走，给大家一个可以照抄的伪代码逻辑：

1. 从CDN下载完整的清单内容（建议先下载到临时文件，不要直接覆盖本地已有清单）。
2. 计算这份新清单的SHA256，如果你在清单里放了校验字段，可以先做一次完整性检查，但这一步不是重点。
3. 用内置公钥验证清单的signature字段。
4. 验证通过后，用这份清单里的resourceVersion和本地当前使用的清单版本做对比。
5. 如果版本号更大，才允许用它作为后续资源对比的基准，否则抛弃并报错或沿用旧版本。

第4步有一个坑，就是版本号回退攻击。攻击者可能截获旧版本的合法签名清单，诱导你的客户端回退到旧资源。怎么防御？如果你的服务和客户端之间有其他通信协议，可以对“热更版本号”也增加一个单调递增的要求，比如客户端本地记录历史最高版本号，任何清单版本不能低于这个记录。如果你的项目有账号体系和服务器，那更简单——服务端下发一个最低允许版本号，客户端低于这个版本就必须强更。

清单验证的C#实现片段参考：

public static bool VerifyManifest(byte[] manifestData, byte[] signature, byte[] publicKey) { using (var rsa = RSA.Create()) { rsa.ImportRSAPublicKey(publicKey, out _); return rsa.VerifyData(manifestData, signature, HashAlgorithmName.SHA256, RSASignaturePadding.Pkcs1); } }

这段代码看起来短，但需要你确保持manifestData是“签名时的原始内容”，而不是对JSON序列化后再序列化的结果。签名和验证永远只针对字节序列，谁都不能中间再走一层编码转换，否则永远验不过。

2.4 CDN配置上的细节：缓存规则、鉴权时长与回源策略

清单一般体积不大，但它的更新频率高、时效性强，所以CDN配置跟AB文件完全不一样。

• 对于清单文件，建议在CDN上设置短缓存，甚至直接“不缓存”。否则你服务器端更新了清单，CDN节点上还是旧数据，玩家死活拉不到新版本。我见过一个项目调试了半天，最后发现是CDN缓存命中导致一直返回旧的Manifest。
• 对于AB文件，建议设置长缓存，因为AB文件名里通常会带上Hash或版本号。文件名变了就是新资源，可以一直缓存不失效；文件名没变，内容理论上就不应该变，缓存多久都安全。

鉴权配置也有讲究。如果你用的是阿里云或腾讯云的CDN，可以开URL鉴权，设置合理过期时间。这个时间不宜太长，建议10到30分钟就够。客户端每次下载前临时拼接鉴权URL即可。但注意，URL鉴权能防白嫖和防盗链，防不了中间人篡改，所以签名校验必须独立做。

回源策略上，CDN回源时一定要使用HTTPS，并且建议开启回源SNI验证，防止回源链路上被劫持。源站的Bucket权限也要仔细检查，读权限适当开放，写权限必须收死。我遇到过一个真实事故，就是团队为了图方便把上传用的临时密钥有效期设置成一年，结果密钥泄露在某个开源项目里，被人在Bucket里塞了一堆垃圾文件。

3. AssetBundle下载、校验与解压落地

3.1 分文件下载or整包下载：流量的真相与增量更新

很多人问热更新时要不要把新资源打成一个大的Zip一起下载。我的建议很直接：商业项目上了正式环境之后，能走增量更新就别走整包更新。原因很简单，玩家手机上可能已经有了大量历史AB文件，整包下载会浪费大量流量和时间，尤其在某些地区弱网环境下，失败率和卸载率会明显增加。

增量更新的做法是，用远端清单里的文件列表和本地清单做对比，找出“新增的、大小变化或Hash变化的”文件，只下载这些差异文件。这样每次更新可能只有一两个很小的AB文件变动，下载消耗非常低。

但增量更新有一个必要条件：你的本地必须有可靠的资源记录。也就是说，每下载一个文件，不能只写磁盘，还要更新本地资源索引。否则下次启动，你没法判断本地哪些文件是新的、哪些是旧的。我见过前期图省事只记录文件名的项目，后面对比逻辑一团糟，每次更新都会重复下载一堆资源。

3.2 Hash校验：下载后的第一道防线

下载完成后，第一件事不是加载，而是Hash校验。你要用清单里的期望MD5/CRC，对下载下来的二进制流重新计算一个Hash值，做比对。不通过，直接丢弃文件，并进入重试逻辑。这一点没有复杂的理论，但工程落地时要注意几个细节：

• 计算Hash时，要用“文件完整写入后”的数据来算，不要用流式计算后就认为没问题。因为写入过程中磁盘可能半路出错。
• 建议使用流式计算，边下载边计算Hash，避免下载完再读一遍大文件。Unity的DownloadHandler配合自定义缓冲区很好实现这一点。
• 如果大面积校验失败，别急着无限重试，先检查CDN上文件是否损坏或上传不完整。我自己就踩过这类的坑，上传工具传了一半就提示成功，CDN上躺着半个文件，玩家校验全部失败。

一个可行的下载校验代码思路：

private IEnumerator DownloadAndVerify(string url, string filePath, string expectedHash, int retryCount) { using (UnityWebRequest request = UnityWebRequest.Get(url)) { yield return request.SendWebRequest(); if (request.result != UnityWebRequest.Result.Success) { // 处理失败重试 yield break; } byte[] data = request.downloadHandler.data; string actualHash = CalculateMD5(data); if (actualHash.ToLower() != expectedHash.ToLower()) { // 校验失败，尝试重试或上报错误 yield break; } File.WriteAllBytes(filePath, data); } }

如果你的工程一开始就跑在一套成熟框架里，比如YooAsset，那么Tools里的下载校验已经保证了这一层。自己实现的好处是你能清楚知道每个环节发生了什么，排查问题时不至于面对黑盒。

3.3 断点续传与重试机制：写下载器容易忽略的四个细节

下载器写多了，我觉得这四个细节特别容易被坑到，值得单独标出来。

第一是临时文件与最终文件的分离。下载时先写到fileName.bin.tmp，整个文件完整、校验通过后，再改名变成正式文件。如果直接写在正式路径，下载到一半的时候崩溃或杀进程，下次启动就会看到半截文件，毒害整个加载链路。养成临时文件+原子重命名的习惯，可以躲避非常多的脏数据问题。

第二是重试次数的上限。不要无限重试，也不要只重试一次。我一般建议3到5次，超过上限后就报错并记录到日志。无限重试在弱网下会拖死整个更新进度，玩家卡在“0%”半天没有反馈，体验极差。限制重试次数后，快速失败并允许玩家稍后重启，反而更好。

第三是重试时机。如果下载失败和网络强相关，立即重试可能还是会失败。建议做指数退避：第一次失败等1秒，第二次2秒，第三次4秒，最多8秒。这个策略简单有效，能极大规避网络抖动造成的连环失败。

第四是速度控制。CDN资源下载时如果完全放开跑，下载带宽占用过高会让玩家游戏内掉帧、音画卡顿。建议对下载速度做限制，比如最大5MB/s，或者至少分帧处理下载循环，避免主线程卡死。UnityWebRequest本身是异步的，但你解析和写文件的操作如果都在主线程，还是会有可见卡顿，建议把文件写盘放到子线程或使用异步IO。

3.4 弱网环境的下载可靠性加固

弱网是热更新最大的敌人。除了断点续传，我的经验里还有几招很实用。

一是同时支持多CDN域名切换。当主力CDN域名连续失败时，自动切换到备用CDN域名。热更新时把域名列表写在配置里，不要硬编码，方便紧急替换。

二是支持下载队列的优先级调整。大文件可以先让位给清单、配置、小文件等关键内容，避免因为一个大AB文件下载缓慢导致全部更新卡住。

三是小文件合并下载。AB文件如果都很小，一次性并发几十个请求会非常浪费连接，且CDN对并发连接数有限制。可以把同批次的几十个小文件合并为一个Bundle（Unity支持合并AssetBundle），减少请求数量，提高弱网下的成功率。

四是对Timeout做合理设置。UnityWebRequest的timeout，不同项目差别很大，我一般设置30到60秒。如果资源包过大、CDN响应慢，更长的timeout也许有必要，但过长的timeout会导致失败后等待太久才重试。用并发下载+动态超时是更科学的做法。

4. 本地缓存的目录结构、校验与防篡改

4.1 persistentDataPath的选择与安全目录规划

资源下载完成后的落盘位置，Unity里最常用的是Application.persistentDataPath。这个路径是加密的沙盒目录，比起Application.streamingAssetsPath和Application.dataPath，用户可见性和修改难度都要高不少，用来放热更缓存没问题。

但目录规划需要提前设计，别把下载的文件直接铺在persistentDataPath根目录。我推荐的目录结构长这样：

persistentDataPath/ ├── hotupdate/ │ ├── manifest/ │ │ ├── current.manifest │ │ └── current.manifest.sign │ ├── bundles/ │ │ ├── assets/res/characters/hero_walk.ab │ │ ├── assets/res/effects/skill_fire.ab │ │ └── ... │ ├── tmp/ │ │ └── (下载中的临时文件) │ └── download.log └── ...

manifest和bundles严格分离，下载临时文件放在tmp目录下，这样清缓存时直接删掉整个hotupdate目录即可，不会误删其他数据。同时，这个目录结构也便于你后续做磁盘空间统计、清理策略等。

需要提醒的是，persistentDataPath并不绝对安全——在Android上，如果用户root并挂载读写文件系统，还是可以直接翻进去篡改文件的。但绝大多数普通玩家不会这么做，这套目录结构已经能把“普通用户误改”和“轻度攻击”挡在外面。

4.2 双份校验：下载时校验一次，加载时再校验一次

下载完成时做Hash校验只是第一道防线。更严格的做法是加载AssetBundle之前再做一次校验，因为文件在磁盘上躺着的这段时间可能需要保证没被动过。

具体做法：在加载每个AB文件时，先读取文件二进制（或者用FileStream流式计算），算出Hash和清单里的期望值对比，如果匹配才调用AssetBundle.LoadFromFile。这里的成本主要在IO和CPU，所以对于大包体建议只做采样校验（比如算文件开头1MB的Hash）或者只对清单中标注为“关键资源”的文件做全量校验，其余文件放宽松一点。

不过，纯技术上的“每次加载都校验”也不必要，性能和体验会受影响。我建议至少做到：

• 清单本身每次启动都校验签名。
• 最近一次热更下载过的文件，启动时采样校验。
• 关键资源（比如启动场景、核心UI、角色初始模型）每次加载前全量校验。
• 普通商街、音效、次要特效等文件，只在下载时校验，加载时不再重复。

这个策略比较贴合真实项目的性能约束和风险偏好，既不会拖慢启动流程，又能把最重要的资源安全线守住。

4.3 缓存清理策略：LRU、磁盘预警与异常文件兜底

热更新做久了，磁盘空间是迟早要面对的问题。缓存目录如果无限膨胀，不光占玩家空间，也会让启动时对比文件列表的时间越来越长。我的建议是维护一个“最近使用时间”列表。每次成功加载某个AB文件时，更新它的最后访问时间。当磁盘使用量超过阈值（比如500MB），按LRU顺序清理最久没用的文件，直到降到安全水位。

清理策略里有个大坑：千万不要在游戏运行时清理正在加载的AB文件，否则要么加载崩溃，要么文件写入冲突。要清理，就在启动流程的“热更检查”阶段集中清，或者放在后台且确保没有AssetBundle还持有引用时再做。

另外，缓存目录里如果出现了清单里不存在的文件，说明可能是被篡改的垃圾文件或上轮异常残留，应当做兜底删除。做法是定期扫描缓存目录，把不在清单中的文件列出来，确认不是临时文件后删除。这也能避免不法分子往你缓存目录里塞木马文件。

4.4 加载过程中的AB引用关系安全

AssetBundle之间存在依赖关系，如果资源A引用了在Bundle B中的资源，而B被提前Unload或者被清理，加载A就会丢引用。这不是安全问题，但会暴露热更版本不一致的隐患：老客户端带着旧AB，遇到新版本清单依赖关系变化，加载崩溃率会飙升。

所以在热更启动时，必须先对齐“本地资源版本”和“清单资源版本”，如果版本不一致，宁可先整包清理缓存重新下载，也不要加载旧资源硬跑。很多线上事故的根源就是 “客户端判断资源不完整后只下载缺失文件，但本地残留的旧依赖和新文件之间存在兼容性问题”。

更安全的做法是在加载AB时，用AssetBundleManifest生成依赖列表，先加载所有依赖，再加载目标AB，并按引用计数统一管理卸载。这种做法和YooAsset的资源回收机制比较相似，如果你们用自研框架，值得花时间把这套依赖管理抄一遍。

5. 实际案例：从定位到修复的一次完整排查实录

5.1 案例一：清单校验绕过导致的全员回退漏洞

有个朋友的项目，热更清单一直没做签名校验。某次活动更新上线后，玩家社区立刻有人放出“一键回退旧版本”的工具。原理很简单：攻击者抓包拿到历史版本的合法清单，然后把它伪装成最新清单发给客户端，客户端不校验签名，直接就按旧清单去下载旧资源，于是所有玩家都被“降级”到没有任何新内容的版本。虽然不至于丢数据，但活动直接白开，运营侧损失是看得见的。

排查时思路也很清晰：先看客户端是不是压根没做签名校验——果然，清单下载完直接解析JSON用。修复就三步：服务端增加私钥签名，客户端增加公钥验签，再给客户端加上“清单版本号必须单调递增”的硬性约束。上线后这个漏洞彻底堵死。

这类问题最容易发生在研发周期紧、赶版本的阶段。我强烈建议把“签名校验”作为热更模块的最低要求，而不是安全增强项来对待。没有签名，你们的热更系统说到底就是一个“人尽可改”的公共资源读取器。

5.2 案例二：CDN节点异常导致部分玩家下载到坏文件

另一个项目遇到的是部分玩家热更失败率奇高，报错集中在某几个AB文件上。检查服务端和构建记录，发现构建机上传资源时，有几次没上传完整就标记成功；另外还有一次是CDN回源到旧Bucket，玩家下载到的AB内容是旧版本，跟新清单的Hash不匹配。

定位过程是靠客户端错误埋点把“校验失败的文件路径+期望Hash+实际Hash”上报上来，汇总之后发现集中在同一批文件上。最后修复措施分两层：第一，构建机上传流程增加上传完成的文件大小校验，务必比对本地上传文件和远端文件的MD5一致；第二，CDN回源URL绑定到固定的版本化目录，例如/hotupdate/20240416_001/，避免不同版本之间的目录串扰。

这起事故教会我两件事：一是上传流程一定要有校验机制，不能相信上传工具返回值；二是CDN资源路径一定要版本化，目录名即版本号，这样CDN缓存再怎么弄也不会串版本。

5.3 案例三：缓存目录被恶意写入后，客户端加载被替换的AB

第三个案例说起来有点尴尬。某个单机向项目没做服务器校验，攻击者定位到persistentDataPath下的AB文件，把某个角色模型Bundle直接替换成低模裸模版本，放到社区炫耀。客户端因为只在下一次启动时重新下载，平时加载完全没校验，导致魔改结果一直生效。

这个其实不算高难度攻击，但恰恰是最普遍的场景。修复的核心是“加载时二次校验”，尤其是把这类明显敏感的资源（角色模型、UI图集）列入关键资源清单，每次加载前强校验Hash。再进一步，可以用对称加密把AB文件在磁盘上做一层加密“保鲜”，密钥内置在客户端，但这样更多是增加攻击门槛，无法杜绝最终被逆向的可能。

做这个项目时我体会到，安全是分层模型：你一层比攻击者深，对方成本高到不值得玩，自然就劝退了。

5.4 排查方法论：日志埋点、错误上报与版本对照表

排查热更新安全问题，光靠肉眼盯代码不行，必须依赖数据。

我建议在热更新链路的关键节点，全部埋点日志。至少包括：清单下载结果、签名验证结果、文件对比差异列表、每个AB的下载耗时、校验结果、加载结果。日志里带上客户端版本号和资源版本号，上报到日志平台。

有了这些数据，排查时建立一张版本对照表：

分类	字段	示例
客户端版本	appVersion	1.3.2
热更资源版本	resourceVersion	20240416_001
清单签名版本	signatureVersion	v3
上报设备平台	platform	Android 14 / iOS 17.4
错误码	errorCode	10021_file_md5_mismatch
缓存路径状态	cachePathStatus	tmp文件残留 / 磁盘空间不足

不同类型的错误码统一编号，错误码里带上模块前缀和具体原因，比如10021_file_md5_mismatch一眼就知道是文件校验失败。这样做问题定位效率至少翻倍，也不用每次排查都去翻客户端日志文件。

6. 安全加固实践清单与后续扩展

6.1 启动时的一致性自检流程

每次启动热更流程，我建议你按固定顺序跑一遍自检：

1. 检查persistentDataPath所在磁盘剩余空间，低于150MB则清理LRU缓存，若清理后仍不足，则拦截热更流程，提醒玩家清理空间。
2. 读取本地已保存的清单，用公钥验签；如果验签失败，直接删除该清单并按第一次启动处理。
3. 检查tmp目录，如有残留的下载临时文件，一律删除。
4. 拉取远端最新清单，验签；如果拉取失败但本地清单是好的，允许玩家进入离线模式。
5. 对比远端和本地清单的差异文件列表。
6. 按上节提到的分级校验策略，对关键文件做启动采样校验。

这套自检流程写成一个ILogger里的检查项列表，跑一次也就几百毫秒，玩家根本感知不到。

6.2 灰度与紧急开关：热更安全的最后两张牌

再好的安全方案，面对线上突发时也需要人的决策。所以热更系统必须带灰度发布能力和紧急回退开关。

灰度发布很简单，清单接口按渠道、按设备ID哈希、按自定义比例返回不同版本的资源清单。这样即使新资源有严重问题，也能只让一小部分玩家踩到，不至于全线崩盘。

紧急回退开关更关键——让服务器可以直接下发“全部回退到上一版本清单”的指令。假设发现某次热更资源包含严重安全漏洞，你可以立即把清单回退到上一版本，客户端看到版本号降低会触发整包回退。但要特别小心，回退操作本身也要防滥用，否则就成了攻击者的版本回退入口。所以回退指令必须叠加服务器端的账号态校验，不能只看清单版本。

6.3 未来可能的方向：双签名、包粒度加密与完整性校验的扩展

再往后做，有几个方向我认为值得留意，看项目需要决定要不要投入：

• 双签名机制：清单由两个不同密钥分别签名，客户端依次验证，即使单一密钥泄露，攻击者也难以伪造完整签名。
• AB文件包级加密：对AB文件做AES加密后下发，客户端加载前先解密到内存再加载。这个做法的痛点是密钥管理，目前公认的稳妥做法是公私钥封装，但落地成本不低。
• 完整性校验上叠加Timing验证：即校验清单里的时间戳和资源版本是否匹配，能抵抗一部分“重放攻击”（把很久以前的合法清单拿过来重放）。这比单调递增版本校验更强一点。

不过说真的，安全建设是成本与收益的平衡。我见过太多团队一上来就追求“绝对安全”，结果热更系统复杂到没法维护，最后反而因BUG导致安全事故。我更推荐按“风险程度”排序，先用最低成本把清单签名、Hash校验、加载时二次校验、版本回退防篡改这四件事做好，再考虑更高级的手段。

7. 踩坑记录与个人心得

写到这里，再分享几个我印象最深的心得。

第一，签名和加密是两码事。签名保证“数据没被篡改”，加密保证“数据不能被直接读懂”。热更安全的核心是前者，不是后者。很多团队花大力气做AB加密，却忘了最根本的清单签名，本末倒置。

第二，本地缓存和CDN缓存对“文件名称”的约束完全不同。CDN适合长缓存，本地缓存必须做LRU和“清单外文件清理”。这两套策略写错任何一个，都会让线上包体越用越臃肿、越用越慢。

第三，任何“下载完就算成功”的代码都是定时炸弹。我曾经写过一个下载框架，下载完后直接写文件，没有做临时文件分离。一次用户磁盘写满，直接生成半截AB文件，后续加载时Unity报错一头雾水，排查了两天才意识到是半截文件导致的问题。从那以后，所有下载必须走“临时文件+校验+原子改名”的路径。

第四，热更问题中80%是版本管理混乱，而不是安全攻防技术。每次发布前检查一下客户端版本、资源版本、签名版本、CDN目录版本这四者之间是否完全匹配，你的线上事故率大概率能下降一个数量级。

最后，如果你还在犹豫要不要做热更安全排查，我的建议是别等出事再动手。先完善日志埋点，确保出问题能定位；然后补上清单签名和Hash校验，这两件事的投入产出比极高，基本能挡住95%以上的外挂和篡改场景。剩下的，随着业务量增长，再慢慢升级。毕竟热更新是一套长期运营的体系，安全的活儿，值得早点干好。