Unity’s Path to CoreCLR: What the Mono Cutover Means for Your Studio

Unity 迈向 CoreCLR：Mono 迁移对您的工作室意味着什么

Unity is replacing its scripting runtime. Not tweaking it, replacing it. The Mono runtime that has sat under every line of C# you have written in Unity for years is being retired in favour of Microsoft’s CoreCLR. It is the most significant change to Unity’s foundation in over a decade, and it is no longer a distant roadmap item: the Unity 6.7 public alpha is out now, with CoreCLR arriving as an experimental option. Unity 正在更换其脚本运行时。不是微调，而是彻底更换。多年来，支撑着您在 Unity 中编写的每一行 C# 代码的 Mono 运行时即将退役，取而代之的是微软的 CoreCLR。这是 Unity 十多年来基础架构中最重大的变革，而且它不再是一个遥远的路线图项目：Unity 6.7 公开 Alpha 版现已发布，CoreCLR 作为实验性选项正式登场。

Most of the coverage treats this as good news wrapped in a version number. It is good news. But if you run a real project, the interesting questions are the practical ones: when does this actually reach me, what changes underneath my game, and what is going to break. Here is that read, from the perspective of a studio that plans and runs Unity upgrades for a living. 大多数报道都将此视为版本号包装下的好消息。这确实是好消息。但如果您正在运营一个实际项目，真正值得关注的是实际问题：这何时会影响到我？我的游戏底层会发生什么变化？什么地方会出问题？以下是从一家以规划和执行 Unity 升级为生的工作室视角出发的解读。

What CoreCLR Is, and Why Unity Is Doing It

什么是 CoreCLR，以及 Unity 为何要这样做

Unity has been running a heavily customised fork of Mono for years. That custom fork is the reason Unity has always trailed the wider .NET ecosystem: while the rest of the C# world moved to modern runtimes, garbage collectors, and language features, Unity developers looked on from behind a runtime that could not easily keep pace. 多年来，Unity 一直在运行一个深度定制的 Mono 分支。正是这个定制分支导致 Unity 在更广泛的 .NET 生态系统中始终处于滞后状态：当 C# 世界的其他部分转向现代运行时、垃圾回收器和语言特性时，Unity 开发者只能守着一个难以跟上步伐的运行时望洋兴叹。

CoreCLR is Microsoft’s modern, open-source .NET runtime, the same one that powers current .NET. Moving to it does three things at once: it gives Unity a far more capable runtime and garbage collector, it unlocks modern C# and the current .NET library ecosystem, and it dramatically improves iteration time, the write-save-wait-for-domain-reload loop that quietly eats hours of every Unity developer’s week. CoreCLR 是微软现代化的开源 .NET 运行时，也是驱动当前 .NET 的核心。转向它能同时实现三件事：为 Unity 提供功能更强大的运行时和垃圾回收器；解锁现代 C# 和当前的 .NET 库生态系统；并显著缩短迭代时间——即那个在每周悄悄吞噬 Unity 开发者数小时时间的“编写-保存-等待域重载”循环。

Unity 6.8 is expected to target .NET 10 and C# 14. To make room for it, Unity has done something telling: it paused new work on animation and world-building workflows specifically to concentrate engineering on this migration and on architectural stability. That is a company choosing foundations over features, which is the right call, and a sign of how big this change is. Unity 6.8 预计将支持 .NET 10 和 C# 14。为了给它腾出空间，Unity 做了一件很有说明意义的事：暂停了动画和世界构建工作流的新开发，专门集中工程力量进行此次迁移和架构稳定性建设。这是一家选择“基础重于功能”的公司，这是正确的决策，也标志着这次变革的规模有多大。

The Timeline That Actually Matters

真正重要的时间表

The migration lands across two releases, and the distinction between them decides what you should do. 此次迁移将分两个版本进行，它们之间的区别决定了您应该采取的行动。

Release	What happens	Your posture
6.7 (alpha now, LTS targeted late 2026)	CoreCLR arrives as an experimental, opt-in scripting backend, desktop first, sitting alongside Mono and IL2CPP	Test in a branch. Do not ship on it.
6.8 (targeted late 2026)	Mono is removed entirely. CoreCLR becomes the foundation of the C# layer. No Mono option remains.	This is the real cutover. Plan for it now.

版本	发生了什么	您的应对姿态
6.7 (现为 Alpha 版，LTS 预计 2026 年底)	CoreCLR 作为实验性、可选的脚本后端引入，优先支持桌面端，与 Mono 和 IL2CPP 并存	在分支中测试。不要用于正式发布。
6.8 (预计 2026 年底)	Mono 被彻底移除。CoreCLR 成为 C# 层的基石。不再保留 Mono 选项。	这是真正的切换。现在就开始规划。

Two things worth internalising. First, Unity has been explicit that 6.8 aims for holistic performance parity first, not a blanket speed-up. Some things will be faster, some slower, and the larger gains come over time as the runtime settles. Treat promises of instant performance with appropriate scepticism. Second, because 6.7 is where you can first put hands on CoreCLR, it is the release to experiment with, even though 6.8 is where the decision becomes unavoidable. 有两点值得铭记。首先，Unity 已明确表示 6.8 的首要目标是实现整体性能的对等，而不是全面的速度提升。有些地方会变快，有些会变慢，随着运行时的稳定，更大的收益会随时间显现。对于“性能瞬间提升”的承诺应保持适当的怀疑。其次，由于 6.7 是您首次接触 CoreCLR 的版本，它是进行实验的最佳版本，尽管 6.8 才是决策变得不可避免的时刻。

What Changes Under the Hood

底层发生了什么变化

The garbage collector is the headline. Mono uses the Boehm GC, which is conservative and non-moving: it cannot always tell precisely what is a live object, and it never relocates memory. CoreCLR brings a precise, moving, generational GC. It knows exactly which objects are live, and it can compact memory. In practice that means less collection overhead and fewer of the stalls that show up as frame hitches. For anyone who has spent time chasing GC spikes in a Unity profiler, this is the change that matters most. 垃圾回收器（GC）是重头戏。Mono 使用的是 Boehm GC，它是保守且非移动式的：它无法总是精确判断什么是存活对象，且从不重定位内存。CoreCLR 带来了精确、移动式、分代式的 GC。它能准确知道哪些对象是存活的，并能压缩内存。在实践中，这意味着更少的回收开销和更少的表现为帧卡顿的停顿。对于任何曾在 Unity Profiler 中追踪 GC 峰值的人来说，这是最重要的变化。

The memory allocator changes too. Unity is integrating MiMalloc, Microsoft’s high-performance allocator, which handles the locking problems that hurt multithreaded allocation. If your project makes serious use of the C# Job System, that code gets more stable and more predictable under load essentially for free, just from the engine update. 内存分配器也发生了变化。Unity 正在集成微软的高性能分配器 MiMalloc，它解决了损害多线程分配的锁竞争问题。如果您的项目大量使用了 C# Job System，那么仅通过引擎升级，您的代码在高负载下就会变得更加稳定和可预测，这几乎是“免费”获得的收益。

The C# and serialisation story improves. Beyond the language and library modernisation, Unity 6.7 adds native serialisation for Dictionary<TKey, TValue>, something the community has wanted for years and worked around with ISerializationCallbackReceiver gymnastics. Unity is also removing the old and insecure BinaryFormatter, which is a security improvement but a real migration item if your project or a dependency still uses it. C# 和序列化的体验得到了改善。除了语言和库的现代化之外，Unity 6.7 还为 Dictionary<TKey, TValue> 增加了原生序列化支持，这是社区多年来一直渴望的功能，此前只能通过 ISerializationCallbackReceiver 的复杂技巧来绕过。Unity 还将移除陈旧且不安全的 BinaryFormatter，这虽然是安全性的提升，但如果您的项目或依赖项仍在使用它，这将是一个实际的迁移任务。

Iteration gets faster. This is the day-to-day win that every developer on the team feels: compile and domain-reload times come down. On a large project, that is hours back per developer per week. 迭代速度变快了。这是团队中每位开发者都能感受到的日常红利：编译和域重载时间缩短了。对于大型项目而言，这意味着每位开发者每周能节省数小时的时间。

The Nuance for Mobile and Console: IL2CPP Is Not Going Away

移动端和主机端的细微差别：IL2CPP 不会消失

This is the part a lot of the excitement skips, and it is the part that matters most if you ship where we ship. CoreCLR is a JIT runtime. It is aimed first at platforms that permit JIT compilation: desktop and the editor. But iOS, the consoles, and other restricted platforms require ahead-of-time compilation, and that is exactly what IL2CPP does. 这是许多兴奋的讨论中被忽略的部分，但如果您像我们一样在这些平台发布游戏，这部分至关重要。CoreCLR 是一个 JIT（即时编译）运行时。它首先针对的是允许 JIT 编译的平台：桌面端和编辑器。但 iOS、主机和其他受限平台需要 AOT（预先编译），而这正是 IL2CPP 所做的。

Unity has been clear that it has no plans to retire IL2CPP. So the real change is not “Mono to CoreCLR” across the board. It is that the old choice of Mono versus IL2CPP becomes a new choice of CoreCLR versus IL2CPP, with CoreCLR replacing Mono as the JIT option and IL2CPP continuing as the AOT option. Unity 已明确表示没有计划淘汰 IL2CPP。因此，真正的变化并非全面从“Mono 转向 CoreCLR”。而是旧的“Mono 与 IL2CPP”选择变成了新的“CoreCLR 与 IL2CPP”选择，CoreCLR 取代 Mono 作为 JIT 选项，而 IL2CPP 继续作为 AOT 选项。

The honest implication for a mobile team: your production iOS and console builds will very likely still go out through IL2CPP for the foreseeable future. That means the immediate, guaranteed win from this migration for a mobile studio is faster iteration and a modern .NET foundation across the team, rather than an automatic reduction in on-device GC stalls on your shipped AOT build. The deeper runtime and GC gains land where CoreCLR actually runs. Knowing which improvements apply to which of your targets is the difference between planning this well and being surprised by it. 对于移动开发团队而言，诚实的结论是：在可预见的未来，您的 iOS 和主机生产版本很可能仍将通过 IL2CPP 发布。这意味着对于移动工作室来说，此次迁移带来的直接且确定的收益是更快的迭代速度和团队范围内现代化的 .NET 基础，而不是您发布的 AOT 构建版本中设备端 GC 停顿的自动减少。更深层的运行时和 GC 收益将体现在 CoreCLR 实际运行的地方。了解哪些改进适用于您的哪些目标平台，是做好规划还是被突发状况打乱阵脚的关键区别。

What Will Break, and What to Check Now

什么会出问题，现在该检查什么

The migration risk does not sit in your gameplay code. It sits at the boundary between managed C# and native code. Unity’s own engine code, and a great deal of third-party plugin code, was written around the behavior… 迁移风险不在于您的游戏逻辑代码，而在于托管 C# 代码与原生代码之间的边界。Unity 自身的引擎代码以及大量的第三方插件代码，都是围绕着……的行为编写的。