企业官网建设流程全解析

搞Unity三年多了，我发现自己带过的每个项目组在资源加载这件事上，几乎都经历过一轮从“全场景拖引用”到“开始用Resources”再到“被迫切AssetBundle”的循环。这玩意儿看似简单——不就是把游戏里的模型、贴图、音频、配置读进来嘛，但真到了做大型项目、要做热更新、要控制包体、要管理内存的时候，资源加载方式选错了，后面返工的成本足够你喝一壶的。

这篇东西我打算一次性把Unity里加载资源的主流方式从头到尾捋一遍：从最简单的Inspector拖引用，到Resources.Load，到AssetBundle打包加载，再到现在的Addressables，外加编辑器里才用的AssetDatabase和StreamingAssets读外部文件这些边角料。每种方案我都会讲清楚它的原理、适用场景、坑在哪，以及我实际项目里踩过的雷。不管你是刚入门想搞清楚Resources和AssetBundle区别的新手，还是正在纠结要不要从AssetBundle迁到Addressables的老手，这篇文章应该都能给你一个相对完整的决策参考。

1. 先想明白：资源加载到底在解决什么问题

很多新手学资源加载，第一反应是“把资源弄到场景里能用就行”，这个理解没有错，但太浅了。等你真到了做项目的阶段，会发现资源加载本质上是在解决两件事：资源从哪来，以及资源什么时候从内存里走。第二个问题比第一个更重要，也更容易被忽视。

1.1 资源生命周期这件事

Unity里的资源，从磁盘上的文件（或AssetBundle包里的数据）到能被游戏逻辑使用的对象，中间要经过加载、实例化、引用、卸载这几个阶段。你用Resources.Load或者AssetBundle.LoadAsset拿到的那个对象，本质上是引擎在内存里创建的一份资源副本或共享实例。这份内存什么时候释放，取决于两件事：你是否还持有它的引用，以及引擎的资源和场景管理机制是否认为它“无用”。

我用个生活化的类比：资源加载就像是去仓库取货。Resources.Load相当于你知道货就在仓库固定的货架上，报个货号就能取。AssetBundle相当于外面运来的集装箱，你得先确认集装箱到了（下载或读文件），再从里面拆箱取货。而卸载资源，相当于把不用的货退回仓库，但退回是有条件的——你得确保没有人在用这批货，否则就会出现“货还在柜台，仓库把货标记成已回收”的尴尬，轻则白加载一次，重则引用失效。

1.2 内存、引用和卸载的三角关系

在Unity里谈资源加载，永远绕不开这三个东西：

• 资源对象（Asset）：磁盘上那个源文件在内存中的体现，比如一张纹理、一个材质、一个模型。
• 实例对象（Instance）：你把它放到场景里实际使用的副本，比如GameObject就是预制体资源的一个实例化结果。
• 引用计数：谁在指向这个资源，决定它能不能被卸载。

这三者的关系，决定了你什么时候该用Instantiate，什么时候该用Resources.Load，什么时候该用AssetBundle.LoadAsset。我在下面每个方案里都会反复回到这个三角关系上，因为这才是资源加载的核心逻辑。

2. 最基础的方式：Inspector序列化引用

先从最不起眼也是日常最常用的方式说起——直接在Inspector面板上把资源拖到脚本的公共字段里。这种方式很多人不把它当“加载”，但它确实是一种加载方式，而且对很多场景来说是最优解。

2.1 序列化字段的原理与用法

在MonoBehaviour脚本里写一个public GameObject prefab;或者public Texture2D icon;，然后在Inspector上把对应的资源拖进去。这个操作的本质，是Unity编辑器把资源的引用信息（GUID和文件ID）序列化进了场景文件或预制体文件里。构建游戏时，Unity会分析场景和预制体里所有被引用的资源，把它们自动打进包内。运行时，引擎直接反序列化这些引用，资源就已经可用了，不需要任何代码加载逻辑。

public class UIPanel : MonoBehaviour { public GameObject rowPrefab; // 拖引用 public Sprite defaultIcon; // 拖引用 public AudioClip clickSound; // 拖引用 }

这段代码的场景，在界面上动态生成列表项时，直接用Instantiate(rowPrefab)。你不需要管加载，不需要管卸载，Unity引擎会在场景卸载时自动处理这些资源的引用清理。

2.2 序列化引用的优缺点

这个方式的优点是显而易见的：零学习成本、类型安全、编辑直观、构建时依赖自动分析，你拖进去的东西一定在包里。但缺点同样明显：

• 无法动态控制：打包的时候，凡是场景或预制体引用的资源，不管游戏实际用不用，都会被打进安装包里。
• 不便热更新：如果你想要换皮、改资源而不重新发包，拖引用的资源全都打在了包里，更新不了。
• 内存控制粒度粗：整个场景引用的资源会在场景加载时一次性全部加载到内存。假如一个UI面板引用了一堆只在特定界面才用的大图，那这个面板所在场景加载时这些图都会被拉进内存。

我在一个小游戏项目里的实际感受是：对于制作周期短、玩法简单、不怎么热更新的项目，无脑用拖引用是最省心的。你省掉的不只是学习成本，还有十几套加载策略的维护成本。但一旦游戏体量上来、要搞热更，就必须引入下面的动态加载方案了。

2.3 什么时候别用拖引用

我的建议是，下面这些情况尽量别用拖引用：

• 资源特别多且很多只在特定条件下才出现（比如皮肤、关卡数据）。
• 需要频繁更新的运营资源（活动图、公告弹窗）。
• 资源来自服务器或玩家设备目录（外部文件）。
• 团队多人协作时经常冲突的场景资产。

3. Resources目录与Resources.Load：最经典的入门方案

聊到动态加载，绝大多数人第一个接触的就是Resources.Load。这也是网上教程最多、争议也最大的一个方案。它好用，但也容易被滥用，而且用坏了之后会让项目构建时间爆炸。

3.1 Resources.Load的基本用法与目录规则

Resources是Unity里一个具有特殊语义的文件夹名。凡是放在名为Resources的文件夹下的资源，Unity都会无条件打进安装包，并且保留路径信息，运行时可以通过Resources.Load按路径加载。

// 加载Resources/Configs/playerConfig.json文件（去掉扩展名） TextAsset config = Resources.Load<TextAsset>("Configs/playerConfig"); PlayerConfigData data = JsonUtility.FromJson<PlayerConfigData>(config.text); // 加载Resources/Prefabs/Enemy.prefab并实例化 GameObject enemyPrefab = Resources.Load<GameObject>("Prefabs/Enemy"); GameObject enemy = Instantiate(enemyPrefab, spawnPoint, Quaternion.identity);

几个关键规则你必须记牢：

• Resources.Load的路径是相对于任意名为Resources的文件夹的，不需要也不需要写扩展名。
• 项目中允许存在多个Resources文件夹（Assets下每个子目录里都可以有一个），构建时它们会被合并到同一个虚拟根目录下，路径不能重复。
• Resources.LoadAll<T>(path)可以加载某个子目录下的所有同类资源。
• 异步版本是Resources.LoadAsync，用法基本一致，返回ResourceRequest。

3.2 Resources目录的代价：为什么要谨慎使用

Resources目录最大的问题是：所有塞进这个目录的资源，无论是否被加载，都会无差别地打进正式包里，且没有依赖裁剪机制。我曾经接手过一个项目，之前的开发图省事，把所有美术资源按原图分辨率塞进了Resources文件夹，结果包体直接从300MB飙到1.2GB，而且每次打一次包要半个多小时，因为引擎要处理海量资源的序列化和索引构建。

另外，Unity官方过去很长一段时间都在建议开发者在正式项目中谨慎使用Resources，核心理由有三条：

1. 包体不可控：Resources目录不做依赖检查，放了就进包，删了忘记清理就会残留。
2. 启动和内存负担：构建会为Resources生成一个索引文件，全量加载到内存，资源过多会拖慢启动和内存占用。
3. 热更新是无解的：Resources目录的东西全在包内，玩家没法从服务器增量更新。

3.3 适合用Resources的场景

尽管它有这么多问题，但在下面这些场景里，Resources依然是合理选择：

• 游戏启动时必须要用、且一定会用的小型资源（比如启动Logo、公共UI组件、全局Shader）。
• 不打算热更新且数量可控的配置数据（比如基础数值表、本地化文本）。
• 制作中的Demo或原型验证阶段，没必要上AssetBundle和Addressables。
• 插件SDK自带的内部资源（这是很多第三方插件至今仍用Resources的原因）。

我在自己独立开发的几个小项目中，至今仍然会在Resources里放一份通用的默认UI皮肤和少量启动配置，用起来确实高效，也不会造成什么负担。关键是想清楚边界：设置一个红线，Resources目录里只放“必须打进包且启动就要用”的东西，其他的走动态方案。

4. 从外部加载：StreamingAssets、持久化目录与网络请求

很多时候资源不在包里，而在服务器、在本地的可读写目录，甚至要从网络上临时拉取。这就涉及Unity里另一类加载方式。必须提前强调：Unity不能像传统桌面程序那样直接File.ReadAllBytes读取任意路径，尤其是在移动平台和WebGL上有非常严格的沙盒限制。

4.1 StreamingAssets：只读的外部资源目录

StreamingAssets是Unity另一个特殊文件夹。它的特点是：文件夹里的内容原样保留在安装包中，不经过任何压缩和打包处理，运行时可以按路径读取。这个目录适合放一些需要“按原始文件格式”读取的资源，比如FFmpeg转码用的视频文件、语音识别用的模型文件、或者你自己加密过的关卡数据。

路径获取方式：

string streamingPath = Path.Combine(Application.streamingAssetsPath, "levels/level_01.bin");

但这里有一个大坑：在Android平台上，Application.streamingAssetsPath指向的是APK内部的压缩路径，普通的File类API读不了，必须用UnityWebRequest来读取。

IEnumerator LoadConfigFromStreamingAssets(string fileName) { string path = Path.Combine(Application.streamingAssetsPath, fileName); using (UnityWebRequest request = UnityWebRequest.Get(path)) { yield return request.SendWebRequest(); if (request.result == UnityWebRequest.Result.Success) { byte[] data = request.downloadHandler.data; // 拿到原始字节，自行解析 } } }

在iOS和PC上，streamingAssetsPath大多是正常的文件系统路径，File.ReadAllBytes就能直接读。所以写跨平台读取逻辑时，要对平台做区分。这个细节很容易在开发机上一切正常、打包到Android上就黑屏不显示，排查半天才发现是文件读取方式的问题。

4.2 持久化目录：下载资源的最佳归宿

Application.persistentDataPath是游戏的可读写沙盒目录，适合存放从服务器下载的AssetBundle、存档数据、玩家截图等。这个目录随安装而创建、随卸载而清除，不需要申请额外的存储权限（Android上应用私有目录不需要运行时权限）。

资源下载管理的标准套路是：服务器下发资源清单（版本号、文件名、哈希、大小）→ 客户端比对本地已有文件，下载缺失或哈希不一致的文件 → 存到persistentDataPath→ 加载时优先从persistentDataPath读取，读不到再回退到包内。

这一步是热更新和资源分包的基础，但Unity本身并没有内置这套“清单比对”逻辑，通常需要自己写，或者借助第三方的热更框架来做。

4.3 用UnityWebRequest加载图片和音频

UnityWebRequest不只是用来读StreamingAssets。从网络或本地加载Texture2D、AudioClip、AssetBundle都用得上。

IEnumerator LoadRemoteTexture(string url) { using (UnityWebRequest request = UnityWebRequestTexture.GetTexture(url)) { yield return request.SendWebRequest(); if (request.result == UnityWebRequest.Result.Success) { Texture2D tex = DownloadHandlerTexture.GetContent(request); _image.material.mainTexture = tex; } } }

UnityWebRequestAssetBundle.GetAssetBundle则是从URL加载AssetBundle的标准方式，后面讲AssetBundle时还会展开。

这里有一个我反复强调的细节：UnityWebRequest在WebGL平台上的内部实现是基于浏览器的Fetch/XHR的，它和桌面/移动端的底层完全不一样，所以有些在编辑器里正常的分段下载逻辑，在WebGL上可能不支持。如果你的项目要出WebGL版本，下载这块一定要提前做兼容性测试，不要等到上线前才发现。

5. AssetBundle：真正能打动态加载的硬核方案

如果你要问Unity里最根本、最灵活的运行时资源加载方式是什么，答案一定是AssetBundle。它是Unity自己的一套资源打包压缩格式，可以把任意资源（模型、贴图、音效、Prefab、场景甚至代码之外的任意文件）打包成一个个文件，由你在运行时决定加载哪些、何时加载、何时卸载。热更新能成立，靠的也是AssetBundle。

5.1 AssetBundle的打包：通过Editor脚本构建

AssetBundle的打包不是把文件夹拖进去就完事，需要写编辑器脚本调用BuildPipeline.BuildAssetBundles。打包时需要指定输出目录、构建目标平台、以及包与资源之间的映射关系（AssetBundleManifest）。

下面是一段我常用的打包脚本基础结构：

// 放在Editor目录下的打包脚本 using UnityEditor; using System.IO; public static class BundleBuilder { [MenuItem("Tools/Build AssetBundles")] public static void BuildAllAssetBundles() { string outputPath = "Assets/StreamingAssets/Bundles"; if (!Directory.Exists(outputPath)) { Directory.CreateDirectory(outputPath); } BuildPipeline.BuildAssetBundles(outputPath, BuildAssetBundleOptions.ChunkBasedCompression, EditorUserBuildSettings.activeBuildTarget); } }

里面有两处要特别说明。第一个是BuildAssetBundleOptions.ChunkBasedCompression，我习惯用这个而不是默认的None或LZMA。None完全不压缩，包体大但加载快；LZMA压缩率高但加载时需要整体解压；ChunkBasedCompression是LZ4按块压缩，加载时只解压用到的块，在包体和加载速度之间取得比较好的平衡。第二个是输出目录，常见做法是输出到StreamingAssets下，这样资源随包发布，运行时直接从本地加载；如果要做完全热更新，则输出到服务器静态目录，客户端通过URL下载。

5.2 资源的AssetBundle归类策略

打包最怕的是把所有资源塞进一个巨大的Bundle里。这样做虽然简单，但会带来两个严重问题：一是玩家为了打开第一章要从一个几百MB的包里解压数据；二是项目更新时任何一个小资源的改动都会导致整个大包重新下载。

我见过比较合理的归类策略是这样几个维度：

• 按功能模块分包：比如UI包、角色包、关卡1包、关卡2包，按界面上线的节奏按需下载。
• 按加载时机分包：启动必须用的资源放小包（如logo、公共UI组件），后期内容放大包。
• 按更新频率分包：极少变化的底层资源（如基础Shader、通用模型）打底包，高频活动资源单独打小包，方便每次活动只下载活动包。

归类策略没有唯一标准，但有一个原则是普适的：不要让玩家为了用一个小功能而下载一个巨大的包。

这里我必须提到AssetBundle的依赖问题。如果你把一个Prefab打进A Bundle，而它引用的材质和贴图在B Bundle里，运行时加载A的Prefab前，必须保证B已经被加载。否则Prefab加载出来会是紫红色（材质丢失）。处理依赖的标准方式是加载AssetBundleManifest，获取当前包的所有依赖包列表，然后按依赖关系逐个加载。

AssetBundleManifest manifest = ...; // 从主Manifest Bundle中加载 string[] dependencies = manifest.GetDirectDependencies(bundleName); foreach (string dep in dependencies) { AssetBundle.LoadFromFile(Path.Combine(bundlePath, dep)); }

5.3 AssetBundle的运行时加载与卸载

运行时加载AssetBundle有四种API：AssetBundle.LoadFromMemory、AssetBundle.LoadFromFile、AssetBundle.LoadFromStream和UnityWebRequestAssetBundle.GetAssetBundle。

LoadFromFile是PC和移动端本地加载最推荐的方式，因为Unity利用文件偏移直接读取，不用把整个文件读入内存再解析，加载速度和内存占用都最理想。LoadFromMemory则需要你把整个Bundle的字节先读到内存里，适合从服务器下载后缓存到本地再加载的场景。UnityWebRequestAssetBundle适合从URL直接加载，Unity内部会处理下载和解析。

从Bundle里取出具体资源：

AssetBundle bundle = AssetBundle.LoadFromFile(bundlePath); GameObject playerPrefab = bundle.LoadAsset<GameObject>("Assets/Prefabs/Player.prefab"); GameObject player = Instantiate(playerPrefab);

这里注意，LoadAsset用的路径是AssetBundle内资源的完整路径，也就是打包时资源在Assets目录下的路径（含扩展名）。如果你不确定路径，可以用GetAllAssetNames()看看包里到底有什么。

卸载是AssetBundle最容易出问题的地方。bundle.Unload(false)只卸载Bundle本身，已加载的资源对象仍然保留在内存中，之后依然能正常使用；bundle.Unload(true)会连同从该Bundle加载出来的所有资源对象一起卸载。如果你调用Unload(true)时场景里还有正在使用这些资源的对象，它们会直接变紫或者报Missing。

我实际项目里总结的安全卸载套路是：先确保所有从该Bundle加载的资源不再被使用（销毁实例、置空引用），再调用Unload(true)。如果确实需要资源对象继续存活，调用Unload(false)，然后让引擎的Resources.UnloadUnusedAssets在合适的时机去回收。后面的方案（比如引用计数管理）本质上都是把这一步做得更自动、更可控。

6. Addressables：官方推荐的现代资源管理方案

如果AssetBundle是“手动挡”，那Addressables就是“自动挡”。它是Unity官方在AssetBundle之上封装的一套资源管理系统，目标是让开发者既不放弃动态加载和热更新的能力，又不必手动写一堆打包、依赖、引用计数的胶水代码。我自己的经验是，只要是做需要长期运营的项目，从一开始就用Addressables，比后期从AssetBundle手写方案迁移要省掉至少两个月的痛苦。

6.1 Addressables解决了什么痛点

单独用AssetBundle时，你要自己操心的事有一长串：

• 资源打哪个包、包与包的依赖关系。
• 加载前是否已加载依赖包、加载后何时卸载、重复加载会不会重复占内存。
• 打包平台切换后Bundle命名和哈希的变化。
• 远程资源更新时旧缓存如何处理。

Addressables把这堆事情都揽了过去。你只需要给资源起一个地址字符串（就叫Addressable key），然后告诉它加载和释放，剩下的打包策略、依赖分析、远程下载、引用计数、缓存管理，由系统统一处理。

6.2 Addressables的基本用法

在Package Manager里安装Addressables后，第一次使用它会提示你创建AddressableAssetsData文件夹，相当于初始化配置。接下来把要动态加载的资源拖进Addressables Groups窗口，系统会给每个资源分配一个地址（默认是资源路径，可以自己改）。

运行时通过地址加载：

using UnityEngine.AddressableAssets; using UnityEngine.ResourceManagement.AsyncOperations; public class ItemFactory : MonoBehaviour { public void SpawnItem(string itemKey, Vector3 position) { AsyncOperationHandle<GameObject> handle = Addressables.InstantiateAsync(itemKey, position, Quaternion.identity); // 返回的handle持有引用，销毁对象时要注意释放 } }

加载普通资源用Addressables.LoadAssetAsync<T>(key)，实例化预制体直接用InstantiateAsync，它内部帮你做了Instantiate和引用记录的整合。释放的时候有对应的一对API：

Addressables.ReleaseInstance(instanceGameObject); // 释放实例 Addressables.Release(handle); // 释放资源

Addressables的底层会自动维护引用计数：你加载一次计数加一，Release一次计数减一，减到零才会真正卸载资源。这个模型彻底避免了手写AssetBundle卸载顺序时“这包里还有没有人用”的噩梦。

6.3 Addressables与Resources和AssetBundle的关系

简单说：Addressables是策略层，AssetBundle是执行层。Addressables打包时默认会把资源按组打成多个AssetBundle，实际加载底层还是AssetBundle.LoadAsset那套机制，只是你不再直接碰Bundle文件。Resources目录里的资源也可以被Addressables接管，只需要把资源拖进Addressables Groups，系统会把它当成普通可寻址资源处理。

从AssetBundle直接手写方案迁移到Addressables，最大的改动在于加载和释放的调用方式变化，以及需要把所有直接引用Bundle路径的代码改成通过Addressable key寻址。不需要把现有资源结构整个推翻重来，Addressables支持把现有资源按组迁移。

我自己迁移一个中型项目时的感受是：前两周会不太适应，老是想去底层找Bundle加载的地方，但用顺以后会强烈怀疑以前为什么手写那套破代码。现在Unity官方在新建项目时几乎默认推荐Addressables，如果你还没入坑，建议直接从Addressables开始学习动态加载，少走弯路。

7. 编辑器专属资源加载：AssetDatabase

讲完运行时的方案，补一个只在编辑器里用的加载方式：AssetDatabase。它在游戏运行时完全不可用（而且编辑器脚本如果在运行时被调用会直接编译错误），但在写编辑器工具、做批量处理、写美术资源导入后处理时，它是主力。

7.1 AssetDatabase.LoadAssetAtPath的用法

AssetDatabase通过资源在Assets目录下的路径来访问资源，不关心GUID。常用形式：

// 放在Editor目录下的脚本 using UnityEditor; public static class AssetProcessor { [MenuItem("Tools/Find Broken References")] public static void FindBrokenFonts() { string[] guids = AssetDatabase.FindAssets("t:Prefab"); foreach (string guid in guids) { string path = AssetDatabase.GUIDToAssetPath(guid); GameObject prefab = AssetDatabase.LoadAssetAtPath<GameObject>(path); // 遍历prefab上的组件引用，检查是否为Null } } }

AssetDatabase.FindAssets是编辑器里一个非常强大的检索API，支持按类型（t:Prefab、t:Texture）、按标签（l:xxx）、甚至按资源名称过滤，配合AssetDatabase.LoadAssetAtPath可以批量处理资源。我做的很多自动化工具，比如批量为所有UI预制体添加组件、批量修改所有精灵的导入格式、检查场景内缺失引用，都是靠这两个API完成的。

7.2 AssetDatabase与运行时加载的区别

AssetDatabase访问的资源是项目工程里的源文件，因此它是未打包、未压缩的原始资源。在这个层面上，AssetDatabase加载和运行时加载对同一个资源的处理是不同的，典型例子是纹理：

• AssetDatabase加载的纹理，你用AssetDatabase.LoadAssetAtPath<Texture2D>拿到的是编辑器当前导入设置下的纹理实例。
• 运行时加载的纹理，是经过构建时压缩和格式转换后的版本。

这就是为什么有时候同一个纹理在编辑器里看着清晰，打进包在手机上发糊——不是AssetDatabase的问题，而是构建时按平台的压缩设置生效了。

顺便说一个常见的坑：AssetDatabase.LoadAssetAtPath需要传入包含扩展名的完整路径，比如"Assets/Art/Textures/icon.png"，不能像Resources.Load那样省略扩展名。

8. 不同方案怎么选：一个务实的决策框架

讲到这里，所有主流方案都过了一遍。我根据自己的项目经验，把它们的核心差异整理成了一张对照表，你可以直接参考：

在此基础上，我给一个可以直接照抄的决策流程：

1. 资源是编辑器里调好的固定依赖、不需要动态决定用哪份？→ 用拖引用。
2. 资源数量少且确定打进包、需要代码按路径加载？→ 用Resources。
3. 资源在包外（服务器或本地可写目录）、格式是非Unity原始资源（如视频、自研格式）？→ 用StreamingAssets或持久化目录+UnityWebRequest。
4. 需要热更新、资源多且要按模块按需加载？→ 直接上Addressables，别先用AssetBundle手写方案。

我有一次做项目，团队起初为了“快”，先用了Resources，后来运营要求热更新，硬生生把所有Resources资源迁移到AssetBundle，改了大概两周的代码，还留下一堆线上缓存问题。如果一开始就用Addressables，这个损失根本不会发生。决策成本远小于迁移成本，这句话在资源加载方案选择上体会特别深。

9. 我实际踩过的坑和排查心得

最后分享几个我觉得真正有价值的实操教训，它们不是文档里会写的，但每一个都是我用加班换来的。

9.1 重复加载导致的内存峰值

有一个界面加载逻辑，我最初写的是每次打开界面都重新Resources.Load一次贴图和字体。结果在配置较差的测试机上，连续开关这个界面十几次，系统内存直接被拉爆。问题在于我没有意识到：Resources.Load同一个资源，如果每次都保留返回的引用，资源就一直不会被卸载，多次加载同一路径实际上都指向同一个已加载实例，但你的引用列表越来越长，引擎的Resources.UnloadUnusedAssets根本扫不到“无用”资源，因为你的引用一个都没放。

后来排查方式是用Memory Profiler抓了一次内存快照，发现同一张纹理被几十个对象持有引用，全是同一个资源。解决办法很简单：把资源引用缓存下来，界面关闭时统一置空引用，再调用Resources.UnloadUnusedAssets。很多内存问题，根因都不是资源太大，而是你持有了一堆永远不会再用的引用。

9.2 AssetBundle卸载顺序导致的材质丢失

手写AssetBundle方案时，我遇到过一个特别隐蔽的问题：A场景卸载了某个Bundle（Unload(true)），但B场景还在用这个Bundle里的一个材质球，导致B场景里一大片模型变紫。排查过程非常痛苦，因为变紫的模型关联的材质已经被卸载了，编辑器里看引用还正常，运行时却报Material Missing。

这让我确立了一个铁律：不管使用Unload(false)还是Unload(true)，都要先梳理清楚“这个Bundle里的资源还有没有地方在用”。手写方案建议做一个Bundle引用计数器——所有从该Bundle加载的资源都登记一次，Release时减一次，计数归零才真正卸载Bundle。这也是后来我果断投入Addressables怀抱的重要原因，它的引用计数机制正是为了根治这类问题设计的。

9.3 异步加载回调里的一个细节

加载资源时用LoadAsync或Addressables.LoadAssetAsync，回调里直接使用加载到的资源创建UI，看起来天经地义，但这里藏着一个跨帧问题。如果异步加载还没完成，界面就已经被用户关闭了，回调回来时你拿着资源创建UI，等于创建了一个已经不应该存在的对象。稳妥做法是回调时先判断发起加载的界面是否还存活，或者干脆用取消令牌配合异步操作，避免资源加载完却用在了错误的时机。

在Addressables里还有一个容易忽略的点：异步操作句柄（AsyncOperationHandle）如果加载失败或加载后从来不放，会造成泄漏。地址写错、资源没进Group、服务端目录名变了，常见排查方式是在Profiler窗口看AssetBundle的内存占用，以及用Addressables.Event Viewer看加载记录，定位是哪一步没释放。

10. 最后再说两句心里话

如果你正在纠结“我的项目到底该用哪个加载方案”，我建议你把项目生命周期拉长来看。只是做个小Demo或者创意原型，拖引用和Resources完全够用，别一上来就上重武器。但如果你心里清楚这个产品会运营很久、会有大量内容更新，那就从第一天用Addressables。我见过太多中途迁移资源加载方案的团队，几乎没有一个不经历重度返工的。

资源加载不是一个炫技的技术方向，它更像是项目管理的一部分。理解每种方式的适用边界，比掌握花哨的API更重要。希望这篇归纳能帮你把Unity资源加载的地图补全，让你在做技术选型的时候能少踩几个我踩过的坑。如果后续有空，我打算再单独写一篇文章，专门拆解Addressables内部的分组策略和远程加载配置，那个坑比想象的要多。