Unity 脚本层与原生引擎层分离架构：原理、实现与工程实践
开场引入
想象这样一个场景：你的 Unity 项目已经在 PlayStation 5 上跑得飞起，老板突然决定要把游戏同步上 Switch。团队里没有 Switch 平台的 C++ 牛人，只有一群写 C# 脚本的逻辑程序员——但即便如此，移植工作依然在几周内完成，没有一行游戏逻辑代码需要重写。又或者，线上项目出现了 GC 卡顿问题，导致 iOS 低端机每隔几秒就卡一次帧，性能工程师把构建后端从 Mono 换成 IL2CPP 并开启增量式 GC（Incremental GC），卡顿峰值明显收敛。
这两个看似神奇的场景背后，藏着 Unity 引擎最核心的架构设计哲学：把「业务逻辑」和「底层引擎」用一条清晰的边界分开，让它们各司其职、独立演化。业务逻辑用 C# 这种高级托管语言编写，享受开发效率、编辑器内快速迭代、生态丰富的好处；底层引擎用 C++ 这种系统级语言编写，吃满硬件性能。这条边界一旦划好，平台移植、性能优化、团队协作都变得顺理成章。
本文将系统拆解这条边界的实现机制——从 Mono 与 IL2CPP 的运行时差异，到托管-原生互操作的细节，再到跨平台抽象的工程哲学，最后落到一份可执行的工程实践清单。
一、Unity 分层架构全景：四层金字塔
1.1 概念定义
Unity 的运行时并不是一个扁平的二进制，而是一个精心设计的四层金字塔。理解这四层之间的关系，是掌握整个架构的第一步。
第四层（顶层）—— C# 业务层
所有用户编写的 MonoBehaviour、ScriptableObjec
