开场：跨语言调用的真实痛点想象这样一个场景：你正在做一款开放世界游戏，需要接入一个用 C++ 写的高性能物理 SDK。厂商只提供了.dll、.so、.a三件套，完全黑盒，既不能改源码也不能编进引擎。与此同时，你在 Profiler 里发现Physics.Raycast、Transform.position这类引擎 API 的调用开销低得反常——同样的数学运算自己用 C# 写一遍反而更慢。这两个场景分别对应 Unity 跨语言调用的两条主线：ICall（Internal Call）——引擎内部 C# 调到 C++ 的私有机制，和P/Invoke——.NET 标准的、调外部原生库的公开机制。不少同学把两者混为一谈，结果该走 ICall 思路的自己写 Native Plugin 绕远路，该走 P/Invoke 的硬写[MethodImpl(InternalCall)]发现根本不生效。下面把这套机制从绑定原理到性能代价彻底讲透。一、核心概念：ICall 与 P/Invoke1.1 ICall：Unity 引擎内部的「直通车」ICall 是 Unity 自定义的绑定机制，核心思路是：C# 层声明方法但不提供实现，运行时在引擎启动阶段被绑定到引擎二进制内部的 C++ 函数。典型的形态是extern方法或属性，配合绑定生成器产出的胶水代码：