Unity不支持用C++编写传统脚本，仅在DOTS中通过Burst编译的Job系统允许受限的C++风格代码；所有MonoBehaviour、Editor脚本及API调用必须使用C#。
Unity 不支持用 C++ 编写传统意义上的“脚本”，Unity C++ Scripting 这个说法本身是误导性的——你无法像写 C# 那样在 Inspector 里挂 .cpp 文件、拖拽赋值、实时重载。所谓“用 C++ 替代 C#”，实际只发生在 DOTS（Data-Oriented Tech Stack）技术栈的特定环节，且有严格边界。
为什么不能直接用 C++ 写 MonoBehaviour 或 Editor 脚本
Unity 的运行时和编辑器完全构建在 Mono/.NET（现为 IL2CPP + Burst）之上，所有公开 API（如 Transform.position、Debug.Log、GameObject.Find）都是 C# 绑定的托管接口。C++ 无法直接调用这些 API，也没有对应的反射系统、序列化支持或生命周期钩子（Start()、Update()）。
- 尝试在
Assets/下放.cpp文件？Unity 完全忽略它 - 用外部 C++ DLL 导入并调用？可以，但只能走
[DllImport]，无法访问 Unity 引擎对象图（Component、Scene等） - 想绕过 C# 直接写 ECS 系统？不行——
SystemBase、EntityQuery、EntityManager全是 C# 类型，C++ 无对应定义
真正能用 C++ 的地方：Burst 编译器 + Jobs System
Unity DOTS 中唯一允许你写接近 C++ 风格代码的路径，是通过 Burst 编译的 IJob 或 IJobParallelFor。它不是 C++，但被编译成高度优化的原生机器码，语法受限于 Unity.Collections 和 Unity.Mathematics 提供的类型系统。
你写的仍是 C# 文件，但会被 BurstCompiler 转换为类似 C++ 的 SIMD 友好指令：
立即学习“C++免费学习笔记（深入）”；
[BurstCompile]
public struct MyPhysicsJob : IJobParallelFor
{
[ReadOnly] public NativeArray positions;
[WriteOnly] public NativeArray velocities;
public void Execute(int index)
{
velocities[index] = math.normalize(positions[index]) * 2.0f;
}}
- 不支持
class、virtual、try/catch、string、Linq
- 必须用
NativeArray 传数据，不能用托管数组 T[]
- 数学运算必须用
Unity.Mathematics.math，而非 System.Math
- 调试困难：断点无效，日志只能靠
DebugLog（需开启 Burst Debug Mode）
想“彻底离开 C#”？只有 Native Plugin + Custom Render Pipeline 这一条窄路
如果你坚持要用 C++ 主导逻辑，唯一可行路径是：把核心模拟（如物理、AI、网络同步）完全抽离到外部 C++ 动态库，通过 [DllImport] 暴露极简 C ABI 接口，再由 C# 层做胶水绑定和 Unity 对象映射。这本质上不是“替代 C#”，而是把 C# 降级为“Unity API 调度器”。
- 典型结构：
C# MonoBehaviour → Marshal.Copy 数据进 IntPtr → [DllImport("sim.dll")] void UpdateSimulation(IntPtr data, int count) → C++ 处理 → 回传
- 代价巨大：内存拷贝开销、GC 压力、无法使用 ECS/Burst 自动调度、调试链路断裂
- 仅适用于已有成熟 C++ 库（如 Havok、Recast）或对性能极端敏感且与 Unity 场景图弱耦合的模块
真正容易被忽略的点是：DOTS 的设计哲学不是“用更快的语言”，而是“用更合适的数据布局 + 显式依赖 + 批处理”。写错一个 [WriteOnly] 标记，或误用 NativeList 在 job 中扩容，性能可能比 C# 还差。别盯着语言，盯紧 EntityQuery 的过滤效率、Archetype 的内存局部性、以及 BurstCompiler 是否真为你生成了向量化指令——这些才是 DOTS 能否跑起来的关键。
