开场凌晨两点，线上版本突然崩溃，日志里全是NullReferenceException和Material doesn't have a texture。原因是某条支线副本里同时加载了上百个 Prefab，引用关系像蛛网一样错综复杂，某个 AssetBundle 被错误卸载，导致贴图丢失。这种翻车场景，几乎每个做过 Unity 中大型项目的同学都遇到过。资源管理看似只是"加载和卸载"，实际上是在异步、缓存、引用计数、跨语言协作之间找平衡。这篇文章先讲清楚为什么 Unity 的资源必须显式管理（而不是交给 GC），再拆一套可落地的分层设计，最后讲 AssetBundle 依赖管理和那些让项目半夜崩溃的坑。一、问题的本质：为什么 GC 管不了 Unity 资源要理解资源管理层存在的意义，先要理解UnityEngine.Object的内存结构。每一个 Texture、Mesh、Prefab 在内存里其实是两份东西：托管壳：C# 侧一个几十字节的小对象，只有一个指向 native 对象的指针；native 实体：真正的贴图像素、网格顶点，躺在 Unity 引擎 C++ 层的内存里，GPU 上还可能有一份上传副本。关键在于：GC 只能看到托管壳。GC 判断"这个 Texture 能不能回收"时，它看到的是几十字节的小对象——没有回收压力；而那 64MB 的贴图数据在 native 堆里，GC 既看