开场凌晨三点，线上项目突然爆出内存泄漏告警，Profiler 显示内存一路涨到 1.2GB。你满头冷汗地把 C# 脚本翻了三遍，GC 也没抓到元凶。最后定位到问题：一个频繁实例化的 Prefab 在销毁时没释放它克隆出来的Material，而这个 Material 引用了一张 4K 贴图——C# 堆上的引用早已断开，但底层 C++ 引擎里那张贴图的 GPU 资源依然死死攥着显存不放。那一刻我才真正意识到：Unity 不只是你写的那些 C# 脚本。它下面藏着一整层用 C++ 写成的庞然大物，正是它决定了一帧画面的生死、一块内存的归属、以及代码究竟能不能跑到 Switch 上。今天我们就来掀开这个"黑盒子"的盖子，回答三个问题：双层架构的边界在哪、两本内存账怎么算、以及 C# 性能短板是怎么被工程手段填平的。一、Unity 引擎的双语言分层架构Unity 采用C++ 核心 + C# 脚本层的双层架构。这是理解整个引擎的第一步。1.1 托管层与非托管层的边界C# 跑在 Mono 虚拟机（或被 IL2CPP 转成原生代码）里，属于托管代码，对象生死由 GC 管理；C++ 引擎直接编译成机器码，属于非托管代码，内存靠引擎自己的分配器和引用计数管理。你的每一个GameObject、Texture2D，其实都是"C# 壳 + C++ 实体"的连体结构：C# 侧只是一个轻量包装对象，真正的数据和状态全在 C++ 堆