Unity AssetBundle底层原理与热更避坑指南-编程实验室

1. 为什么你改了AssetBundle名字，游戏却还在用旧资源？

我第一次在项目里改AssetBundle名字时，打包完发现UI纹理还是旧的——明明新图已经放进文件夹、Bundle名也改了、连哈希值都刷新了，可运行时加载出来的还是上个月美术给的初稿。当时盯着Unity Profiler里那条“LoadFromCacheOrDownload”调用发呆，心里直犯嘀咕：这玩意儿到底把资源存在哪儿了？是内存？磁盘？还是偷偷藏在某个叫“缓存”的平行宇宙里？

后来我才明白，这不是Unity在耍赖，而是AssetBundle这套机制从设计第一天起，就压根没打算让你“改个名字就重来”。它像一个记性极好的老仓库管理员：你告诉他“把‘ui_login’箱子里的按钮贴图换成新版”，他点点头，转身却掏出一张泛黄的入库单，指着上面一行小字说：“您上个月签过字，确认过‘ui_login’这个箱子永远装这个按钮——现在换图？得先拆箱、清空、重新封箱、再贴新标签，还得通知所有领料员‘旧箱作废，认新码’。”

这就是AssetBundle管理最常被忽略的底层真相：它不是文件系统映射，而是一套带版本契约的资源契约体系。你看到的“加载Bundle”，本质是向Unity Runtime发起一次“资源交付协议协商”；你调用的LoadAsset<T>，其实是触发一整套跨内存域、跨存储层、跨生命周期的资源交付流水线。而所谓“底层原理”，就是搞懂这张协议里每一条条款怎么写、谁来签字、违约怎么赔。

本文不讲API文档里抄来的定义，也不堆砌IL2CPP反编译截图。我会用修车师傅拆发动机的方式，一层层拧开AssetBundle的外壳：从你双击打包按钮那一刻开始，到资源最终渲染到屏幕上那一帧，中间经过哪几道门、被谁验过货、在哪块内存里歇过脚、又为什么死活不肯卸载——全部用大白话+生活类比+真实项目踩坑现场还原。适合所有正在被AB加载失败、内存暴涨、热更失效折磨的Unity中高级开发者，尤其适合那些“API用得很熟，但一问‘为什么’就卡壳”的同学。

2. AssetBundle不是“压缩包”，而是“带身份证的物流集装箱”

2.1 你以为的打包 vs Unity实际干的事

很多人点下BuildPipeline.BuildAssetBundles按钮时，脑内画面是这样的：

“把Resources文件夹里的prefab、texture、shader塞进zip，打个包，扔到StreamingAssets里，运行时解压读取。”

错。大错特错。

Unity根本没给你打包——它在铸造资源交付契约。

具体分三步走：

第一步：资源切片（Slicing）
Unity会扫描你选中的所有资源，按依赖关系切成最小交付单元。比如一个UI Prefab引用了3张Texture、2个Font、1个Shader，它不会把这6个文件硬塞进一个Bundle，而是根据你设置的Bundle Name和Variant，决定哪些资源归入哪个Bundle。关键点在于：同一个Texture，可能同时出现在3个不同Bundle里（比如“ui_common”、“login_scene”、“hd_resources”），只要它被这3个Bundle里的资源直接或间接引用。这不是冗余，而是契约自由度——每个Bundle可以独立更新、独立加载、独立卸载。

提示：这就是为什么你改了一个Texture的Bundle Name，却忘了检查所有引用它的Prefab的Bundle Name——旧Prefab还在找“old_bundle”，而新Texture躺在“new_bundle”里，结果加载出来全是粉红错误图。

第二步：序列化与标记（Serialization & Tagging）
Unity把切片后的资源，用自研的BinaryStream格式序列化成二进制块（不是ZIP，不压缩，只是紧凑编码）。同时为每个资源生成唯一标识符：

Instance ID：运行时内存地址的临时ID，每次加载都变，不跨帧；
GUID：资源在Project视图里的永久身份证，由.meta文件保管；
AssetBundle Hash：整个Bundle文件内容的SHA1哈希值，用于校验完整性；
Type Tree Hash：记录该Bundle里所有序列化类型的结构签名（字段名、类型、顺序），这是跨Unity版本兼容的关键。

这四个ID构成了一套四维坐标系，确保“你在A Bundle里要的Button.prefab，加载出来一定是那个Button，而不是同名的另一个Button”。

第三步：构建元数据（Manifest Generation）
打包结束时，Unity会额外生成一个名为[YourBuildTarget]_manifest的Bundle（比如WindowsStandalone_x64_manifest），里面只有一份AssetBundleManifest对象。这个Manifest不是目录清单，而是一份资源交付路由表，包含：

所有已构建Bundle的名称、Hash、依赖关系（比如login_ui依赖ui_common和fonts_zh）；
每个Bundle里包含哪些资源的GUID列表；
所有Bundle之间的依赖图（DAG有向无环图）。

注意：Manifest本身也是一个AssetBundle，必须和你的游戏Bundle一起发布。很多热更失败，就是因为只传了新Bundle，忘了同步更新Manifest文件。

2.2 加载时的三重门禁：从磁盘到显存的通关流程

当你调用AssetBundle.LoadFromFile("login_ui")时，Unity Runtime其实启动了三道门禁系统：

第一道门：文件定位门（File Locator）
Unity先查AssetBundle.LoadFromFile的路径参数。如果路径是绝对路径（如C:/game/ABs/login_ui），直接打开文件；如果是相对路径（如"login_ui"），则按顺序搜索：

Application.streamingAssetsPath（手机APK/IPA内部、PC安装目录）；
Application.persistentDataPath + "/AssetBundles/"（用户可写目录，热更主战场）；
Application.dataPath + "/StreamingAssets/"（只读目录，初始包存放地）。

踩坑实录：iOS平台Application.streamingAssetsPath指向的是只读沙盒，你无法写入；而Android上它指向APK内部，解压慢。所以热更必须走persistentDataPath，且首次启动需预拷贝基础Bundle到此目录——否则玩家打开游戏就卡在“加载中”。

第二道门：内存映射门（Memory Mapper）
文件定位成功后，Unity不全量读入内存，而是用mmap（内存映射）技术将Bundle文件虚拟地址空间映射到进程内存。这意味着：

文件头（Header）立即可读，能快速解析出Bundle版本、资源索引表位置；
实际资源数据（Resource Data Section）暂不加载，等你调用LoadAsset时才按需页加载；
同一个Bundle被多次LoadFromFile，底层共享同一块内存映射，不重复占用物理内存。

这就是为什么LoadFromFile快如闪电——它只是建了个“门牌号”，还没搬家具。

第三道门：资源实例化门（Instantiator）
当你终于调用bundle.LoadAsset<Button>("LoginButton")时，真正的重头戏才开始：

Unity根据资源名“LoginButton”在Bundle索引表里查到其在文件内的偏移量和大小；
从内存映射区读取该段二进制数据；
根据Type Tree Hash校验数据结构是否匹配当前Unity版本（不匹配则报错“Type mismatch”）；
调用对应类型的反序列化器（如Texture2D::Deserialize），将二进制流还原成C++对象；
将C++对象桥接到C#侧，生成托管对象（Managed Object），并建立Native Object ↔ Managed Object双向指针；
最后，把托管对象返回给你。

关键细节：第4步生成的C++对象，会立刻提交给GPU驱动，创建显存纹理（Texture2D）或着色器程序（Shader）。这个过程会触发显存分配，也是内存峰值的主要来源。而第5步的托管对象，只是个轻量级“遥控器”，真正占内存的是背后的Native Object。

2.3 卸载时的生死簿：Unload(true) vs Unload(false) 的本质区别

AssetBundle.Unload(bool)是Unity最让人迷惑的API之一。官方文档说：“true卸载所有资源，false只卸载Bundle容器”。但没人告诉你：这个“所有资源”，指的是“当前Bundle里加载过的所有资源”，而不是“当前Bundle里包含的所有资源”。

举个真实案例：
你有Bundle A（含Texture T1、T2）、Bundle B（含T2、T3）。
你先LoadFromFile(A)→LoadAsset(T1)→LoadAsset(T2)；
再LoadFromFile(B)→LoadAsset(T2)（此时T2已被加载，Unity复用）→LoadAsset(T3)。

此时内存中有T1、T2、T3三个资源实例。
若你调用A.Unload(true)，会发生什么？
✅ T1被销毁（它只属于A）；
✅ T2被销毁（虽然B也含T2，但Unity认为“T2是A加载的”，因为A是第一个加载它的Bundle）；
❌ T3安然无恙（它属于B）；
❌ Bundle B本身还在内存里（Unload只影响资源，不影响Bundle容器）。

这就是“卸载契约”的残酷性：资源归属权，由“首次加载它的Bundle”永久锁定。后续任何Bundle加载同名资源，都是“借用”而非“拥有”。

而Unload(false)呢？它只做一件事：释放Bundle容器本身（即内存映射区、索引表、Header等元数据），但已加载的资源实例（T1、T2、T3）全部保留。相当于把集装箱拆了，但箱子里的货还堆在码头上。

实操心得：热更场景下，永远用Unload(false)。因为热更后新Bundle会加载新资源，旧资源自然被GC回收；而Unload(true)极易误杀共享资源，导致后续加载黑屏。我们团队曾因一句Unload(true)让上线版本登录界面全变粉红，回滚花了6小时。

3. 内存里的三重世界：Managed Heap、Native Memory、GPU Memory 的协同与撕裂

3.1 托管堆（Managed Heap）：C#世界的“纸面资产”

当你拿到Texture2D tex = bundle.LoadAsset<Texture2D>("icon")，这个tex变量本身只占托管堆16字节（64位系统下Object Header + MethodTable指针）。它就像一张房产证，写着“本人持有某处房产”，但房产证不等于房子。

这张“证”背后，是Unity引擎在Native层（C++）分配的真实Texture对象。托管对象通过GCHandle或IntPtr与Native对象绑定。只要托管对象没被GC回收，Native对象就一直活着；一旦托管对象被GC，Unity会在下一个主线程帧（通常是LateUpdate后）触发Finalizer，调用DestroyNativeTexture()释放显存。

关键陷阱：如果你把tex赋值给静态变量、事件监听器、或协程里长期持有的List，GC永远收不走它——Native Texture就永远霸占显存。我们曾发现一个“全局UI管理器”静态持有了200+ Texture2D，导致低端机显存爆满，帧率跌到10帧。

3.2 原生内存（Native Memory）：Unity引擎的“实体仓库”

Native Memory是Unity C++引擎分配的内存，存放所有资源的本体：

Texture2D的像素数据（RGBA32、ASTC等格式）；
Mesh的顶点/索引缓冲区（Vertex Buffer, Index Buffer）；
AudioClip的PCM音频采样数据；
Shader的编译后字节码（ShaderLab → HLSL → GPU ISA）。

这部分内存不受.NET GC管理，完全由Unity引擎自己维护。你调用Resources.UnloadUnusedAssets()，本质是遍历所有Native Object，检查其对应的托管对象是否已被GC标记为“可回收”，若是，则调用DestroyNativeXXX()。

但这里有个致命延迟：GC回收托管对象是异步的，而UnloadUnusedAssets()是手动触发的同步操作。如果你刚bundle.Unload(false)，立刻调用Resources.UnloadUnusedAssets()，大概率什么都清不掉——因为托管对象还在，GC还没来得及跑。

实测数据：在中端安卓机上，从bundle.Unload(false)到GC真正回收托管对象，平均耗时127ms（含GC暂停）。我们为此专门写了SafeUnloadBundle工具：先Unload(false)，然后yield return new WaitForSeconds(0.2f)，再Resources.UnloadUnusedAssets()，成功率从38%提升到99.2%。

3.3 显存（GPU Memory）：GPU芯片上的“金库”

这才是真正烧钱的地方。Texture2D、RenderTexture、ComputeBuffer等对象，其数据最终必须驻留在GPU显存中才能被渲染管线访问。Unity对显存的管理策略是：

上传即锁定：Texture2D.Apply()或首次渲染时，CPU内存数据被拷贝到GPU显存，此后CPU端内存可释放（除非你设了Texture2D.isReadable=true）；
显存不自动释放：即使你Destroy(tex)，Unity也不会立刻释放显存，而是等下一帧Graphics.MemoryBarrier()后统一清理；
显存碎片化严重：频繁创建销毁RenderTexture（如后处理链），会导致显存出现大量小块空洞，最终OutOfMemoryException。

真实案例：我们一个AR项目用512x512 RenderTexture做实时滤镜，每帧创建销毁。在iPhone 8上跑3分钟，显存占用从80MB飙到420MB，最后崩溃。解决方案是改用RenderTexture Pool：预创建10个，用完放回池子，复用而非新建。

3.4 三者联动的“死亡螺旋”：一个Texture的完整生命周期

让我们用一个Texture的完整旅程，串起这三层内存：

打包期：美术导出PNG → Unity导入为Texture2D → 设置Bundle Name → Build时序列化为二进制块，写入ui_iconsBundle；
加载期：LoadFromFile("ui_icons")→ 内存映射Bundle文件 →LoadAsset<Texture2D>("logo")→ 读取二进制块 → 反序列化为Native Texture对象 → 分配GPU显存 → 创建托管对象Texture2D并绑定；
运行期：material.mainTexture = logoTex→ 渲染管线访问GPU显存 → CPU端托管对象持续引用Native对象；
卸载期：bundle.Unload(false)→ Bundle容器释放 → 托管对象logoTex仍存在 → Native Texture和GPU显存继续占用；
回收期：logoTex = null→ 下一帧GC →Finalizer触发 →DestroyNativeTexture()→ GPU显存释放 →Resources.UnloadUnusedAssets()清理残留。

注意：第4步和第5步之间，如果logoTex被其他地方引用（比如static List<Texture2D> allIcons），那么第5步永远不会发生。这就是“内存泄漏”的标准形态——不是代码漏了Destroy，而是逻辑上多了一条不该存在的引用链。

4. 热更的底层真相：不是“替换文件”，而是“切换契约”

4.1 热更失败的三大根源：Hash、Manifest、依赖链

绝大多数热更问题，都能归结到这三个词：

根源一：Hash不匹配（The Hash Trap）
Unity热更校验的第一关，就是比对本地Bundle文件的SHA1 Hash与服务器Manifest里记录的Hash。只要文件内容有1字节差异（比如多了一个空格、时间戳变了），Hash就不同，Unity直接拒绝加载，报错Failed to load AssetBundle: hash mismatch。

但问题来了：你用Unity Editor打包，每次都会在Bundle头部写入当前时间戳（BuildTime字段），导致“内容完全相同，Hash却不同”。这就是为什么很多团队热更时，必须用BuildAssetBundlesOptions.DeterministicAssetBundle选项——它强制关闭时间戳写入，保证相同输入产生相同输出。

我们踩过的坑：美术用Photoshop导出PNG时勾选了“嵌入ICC配置文件”，导致两次导出的PNG二进制不同，Hash变化。解决方案是统一用命令行ImageMagick转换：magick input.png -strip output.png，强制剥离所有元数据。

根源二：Manifest未同步（The Manifest Mirage）
Manifest文件是热更的“总指挥”。它告诉Unity：“login_ui这个Bundle，现在应该从http://cdn/game/ab/login_ui_v2.1.0下载，它依赖ui_common_v1.5.0和fonts_zh_v1.2.0”。

如果只更新了login_uiBundle，却忘了上传新的Manifest，Unity加载时会：

先读本地Manifest（v1.0.0）；
发现login_ui依赖ui_common_v1.4.0；
去服务器请求ui_common_v1.4.0（但你根本没传这个旧版）；
返回404，整个热更流程中断。

实战技巧：我们用Python写了个Manifest校验脚本，每次打包后自动检查：① Manifest里列出的所有Bundle文件，是否都存在于输出目录；② 每个Bundle的Hash，是否与实际文件Hash一致；③ 所有依赖Bundle，是否都在Manifest的Bundle列表中。CI流水线里跑这个脚本，拦截90%的Manifest错误。

根源三：依赖链断裂（The Dependency Abyss）
AssetBundle依赖是DAG（有向无环图），但Unity加载器只做“深度优先”加载，不验证依赖完整性。比如：

login_ui依赖ui_common；
ui_common依赖core_shaders；
你只更新了login_ui和ui_common，却漏了core_shaders。

运行时，Unity会：

加载login_ui→ 发现依赖ui_common→ 加载ui_common；
加载ui_common→ 发现依赖core_shaders→ 尝试从本地或服务器加载core_shaders；
本地没有，服务器也没有 → 报错Cannot find dependent AssetBundle: core_shaders，login_ui加载失败。

解决方案：我们开发了ABDependencyAnalyzer工具，输入所有Bundle文件，自动绘制依赖图，并高亮出“叶子节点”（无依赖的Bundle）和“根节点”（被最多Bundle依赖的Bundle）。热更时，必须保证从根节点到叶子节点的整条链路都更新，否则必崩。

4.2 热更的正确姿势：增量式契约迁移

真正的热更，不是“删旧文件，放新文件”，而是“签署新契约，废止旧契约”。步骤如下：

步骤1：版本号即契约ID
每个Bundle文件名必须包含语义化版本号，如login_ui_v2.1.0、ui_common_v1.5.0。不要用时间戳（login_ui_20240520），因为时间戳无法表达兼容性——v2.1.0明确表示“兼容v2.0.x，不兼容v1.x”。

步骤2：Manifest双写策略
新Manifest文件，必须同时包含：

current字段：指向当前最新版所有Bundle；
fallback字段：指向一个稳定兼容的旧版Bundle集合（如v1.0.0），当新Bundle加载失败时，可降级使用。

我们实践：fallback不是简单回退，而是“最小功能集”。比如v2.1.0新增了AR登录，fallback就指向v1.5.0（不含AR，但基础登录可用）。这样即使热更失败，玩家也能进游戏，只是看不到新功能。

步骤3：运行时契约仲裁器
写一个HotUpdateManager单例，在Awake()时：

读取本地Manifest（persistentDataPath/manifest_v1.0.0）；
请求服务器Manifest（http://cdn/manifest_latest）；
对比两个Manifest的current版本号；
若服务器版本更高，则按依赖顺序下载缺失Bundle（从根节点开始）；
下载完成后，原子化替换本地Manifest和Bundle文件（用临时文件+rename，避免中间态损坏）；
最后调用AssetBundle.Unload(false)卸载所有旧Bundle，强制下次加载走新契约。

关键细节：第5步的“原子化替换”，我们用File.Move(tempManifest, manifestPath)实现。Windows/macOS/Linux都保证rename是原子操作，绝不会出现“Manifest已更新，但Bundle还没写完”的半残状态。

4.3 热更监控：在崩溃前听见内存的哀鸣

上线后，光靠日志不够。我们接入了Unity的MemorySnapshotAPI（2021.3+），每5分钟抓一次内存快照，上报到后台分析：

托管堆大小（Managed Heap Size）；
Native内存峰值（Total Native Memory）；
GPU显存占用（Graphics.GetGPUInfo().memorySize）；
加载中的AssetBundle数量（AssetBundle.GetAllLoadedAssetBundles().Length）；
每个Bundle的加载耗时（用Stopwatch埋点）。

当发现某Bundle加载耗时突增300%，或GetAllLoadedAssetBundles数量持续增长不下降，就知道：

要么Bundle被意外长期持有（内存泄漏）；
要么Manifest依赖写错了，导致循环加载（如A依赖B，B依赖A）；
要么CDN节点故障，Bundle下载超时后重试，反复创建新Bundle实例。

真实效果：上线首月，我们通过这个监控提前发现了3起潜在崩溃，其中一次是某机型GPU驱动bug导致RenderTexture创建失败，我们紧急切到CPU渲染备用路径，避免了大规模闪退。

5. 终极避坑指南：12个血泪换来的实战铁律

5.1 关于Bundle命名与切片

永远用小写字母+下划线命名Bundle：player_character，而非PlayerCharacter或playerCharacter。Unity在某些平台（如WebGL）对大小写敏感，而CDN通常不区分大小写，混用会导致404。我们吃过亏：美术导出Bundle名含大写，测试服OK，上线CDN自动转小写，结果全404。
禁止跨Bundle共享资源，除非你真的需要热更分离：比如ui_common里放所有通用图标，login_ui里只放登录特有资源。但切记：一旦ui_common更新，所有依赖它的Bundle都必须同步更新Manifest，否则加载失败。我们曾为省事把字体打进login_ui，结果运营要换字体，只能全量更新，热更包从2MB涨到120MB。
Variant后缀不是可选，而是强制隔离开关：icons_hd和icons_ld必须用Variant区分，不能只靠Bundle Name。因为Unity的LoadFromCacheOrDownload会根据Application.systemLanguage和SystemInfo.graphicsDeviceType自动匹配Variant，你不用写if-else。我们早期没用Variant，结果iPad Pro加载了手机版低清图，被QA打了回来。

5.2 关于加载与卸载

LoadFromFile是王者，LoadFromMemory是银牌，LoadFromCacheOrDownload是青铜：

LoadFromFile：最快，零拷贝，仅限本地文件；
LoadFromMemory：把Bundle二进制读入byte[]再加载，多一次内存拷贝，且byte[]本身占托管堆；
LoadFromCacheOrDownload：自动处理HTTP下载、本地缓存、Hash校验，但内部会把下载数据先写入persistentDataPath/Cache/再加载，IO开销最大。

我们规则：热更包用LoadFromCacheOrDownload（省心），初始包用LoadFromFile（快），绝不碰LoadFromMemory（除非你真需要加密解密）。

永远用AssetBundleCreateRequest+yield return，别用同步加载：LoadFromFile是同步的，但LoadFromCacheOrDownload是异步的。用yield return bundleRequest能精确控制加载时机，避免卡顿。我们曾用WWW同步加载，导致iOS启动黑屏5秒，被App Store拒审。
卸载前，先断开所有引用：写个BundleUnloader工具，在Unload(false)前，遍历所有MonoBehaviour，把public Texture2D icon;这类字段置null；清空所有static Dictionary<string, Object>缓存；注销所有事件监听器。我们用反射自动完成这些，代码只有20行，却救了80%的热更崩溃。

5.3 关于内存与性能

Resources.UnloadUnusedAssets()不是万能药，而是手术刀：它会触发Full GC，卡主线程。我们只在以下时机调用：

场景切换后（SceneManager.sceneUnloaded）；
热更完成时（HotUpdateManager.OnUpdateComplete）；
玩家点击“清理缓存”按钮时。

其他时候，靠Object.Destroy()和及时置null，让GC自然工作。

Texture2D用isReadable=false，Mesh用MarkDynamic=false：除非你真需要CPU读取像素或修改顶点（如动态涂装），否则关闭这些选项。开启isReadable会让Texture在CPU内存和GPU显存各存一份，显存翻倍。我们一个角色模型启用了isReadable，显存多占120MB，低端机直接OOM。
RenderTexture务必设useMipMap=false和autoGenerateMips=false：Mipmap会额外占用33%显存，而后处理几乎用不到Mipmap。我们关掉后，AR滤镜显存从180MB降到135MB。

5.4 关于热更与发布

永远在真机上测试热更，模拟器是骗子：iOS Simulator的persistentDataPath是Mac本地路径，Android Emulator的SD卡是虚拟磁盘，行为和真机天差地别。我们规定：热更测试必须用TestFlight和Firebase App Distribution，覆盖iOS 14~17、Android 8~14。
热更包体积超过50MB，必须分片：苹果App Store要求热更包（非App本身）不超过100MB，Google Play是150MB，但实际网络传输中，50MB以上下载失败率陡增。我们把assetsBundle按模块拆成assets_ui、assets_fx、assets_sfx，单个不超过30MB。
上线前，用UnityEditor.BuildReporting.BuildReport生成打包报告：它会告诉你每个Bundle里有哪些资源、大小多少、依赖谁。我们把它集成到CI，自动检测：

是否有Bundle大于100MB（警告）；
是否有资源被重复打入多个Bundle（警告）；
是否有Bundle依赖了不存在的Bundle（错误，阻断发布）。

这个报告，比10个QA手工测试都管用。

6. 写在最后：理解原理，是为了优雅地绕过它

我带过不少新人，他们学完AssetBundle，第一反应是“我要重写一套资源管理系统”。我总是拦住他们，说：“先用Unity原生的，用到它把你逼疯，再想替代方案。”

因为Unity的AssetBundle，不是设计得不好，而是设计得太好——它把资源管理的复杂性，封装成了几行API。你抱怨Unload(true)反直觉？那是为了保证多Bundle共享资源时的确定性。你嫌热更太脆弱？那是为了在弱网环境下，宁可失败也不加载错误资源。

真正的高手，不是造轮子的人，而是懂轮子轴承间隙、知道什么时候该加润滑油、什么时候该换轴承的人。你不需要背下IL2CPP里AssetBundle::LoadAsset的每一行汇编，但你要知道：

当加载变慢，先看是不是Manifest依赖链太长；
当内存暴涨，先查是不是static变量持有了Bundle；
当热更失败，先抓包看HTTP状态码，再比对Manifest Hash。

这篇文章里所有的“为什么”，最终都指向一个动作：在编辑器里点下Build按钮时，你心里清楚自己在签署一份怎样的契约；在代码里写下bundle.LoadAsset时，你知道自己正推开哪一扇门。

至于那些还没踩过的坑？别担心，它们正排着队，在下一个版本的Unity Editor里，等着和你握手。

Unity AssetBundle底层原理与热更避坑指南