开场凌晨两点，线上版本突然收到一堆 Crash 报告，堆栈指向OutOfMemoryError。Profiler 一拉，Native 占用飙到 1.8GB，可项目总预算才 1.5GB。更诡异的是，资源引用图看起来一切正常——没有泄漏的 Texture，没有常驻的 AudioClip。这种"看不见的内存膨胀"几乎在每个商业化 Unity 项目里都会上演，根因往往不在"谁没释放"，而在 Native 层分配器本身的行为：它申请过的内存，不一定会还给操作系统。这次我们从引擎的 C++ 心脏地带出发，按「内存空间怎么划分 → Native 分配器内部怎么走 → 工程上怎么治」的顺序，把 Native 内存的来龙去脉拆清楚。一、Unity 进程内存的三大空间理解优化的前提是先看清边界。一个 Unity 进程的内存大致分三块：1.1 程序代码段（Code Segment）引擎 C++ 编译产物、脚本程序集（Mono 下是 DLL，IL2CPP 下是转译后的 C++ 代码）的指令区，通常只读且常驻。能动的优化是代码精简与Strip Engine Code / 裁剪未用引擎模块——它不占"堆"，但会实打实计入系统的内存统计，低端机上不可忽略。1.2 本机堆（Native Heap）——本文主角Unity C++ Runtime 的主战场：纹理上传 GPU 前的 CPU 侧副本、Mesh 顶点数据、AudioClip、MonoBehaviour 的序列化数据、AssetBundle 解压缓冲、NavMesh、UnityWebRequ