1. 为什么Unity项目需要热更新，以及ILRuntime为什么值得关注
做过线上Unity游戏的人，基本都经历过这种时刻：版本上线没几天，线上报了个严重的关卡卡死问题，或者某新手引导文案写错了，又或者策划临时要加个活动入口，而热更新还没接入，那就只能走渠道审核重新发版。轻则等几天，重则挨一顿骂，整个团队都跟着耗。所以热更新对Unity项目来说，不单是技术选型，更是一个生死攸关的基础设施问题。
而ILRuntime，正是为了解决“Unity C#逻辑无法在iOS上动态更新”这个痛点而生的一个热更新方案。它做的事情通俗来说，就是让你的游戏在启动时，从服务器下载一份C#程序集（DLL），然后在运行时由ILRuntime这套解释器去“读”这份DLL里的代码并执行，从而绕开iOS系统对“动态下发并执行代码”的严格限制。项目上只要把核心玩法、活动逻辑、功能开关、UI流程这些容易出问题的部分放到热更DLL里，之后线上出问题，改代码、出包、上传服务器，用户重启游戏就能更新，完全不需要经过应用商店审核。
这篇文章适合谁看？如果你在负责Unity项目的热更新方案选型，或者已经在用ILRuntime但遇到了性能、报错、架构上的坑，又或者你只是在了解市面上几种热更新方案的差异，那么这篇内容都值得你从头到尾读一遍。我会把ILRuntime的原理、接入步骤、踩坑经验、性能优化思路一次性讲透，尽量用做项目时真正会遇到的问题来说话，而不是给你贴一堆文档。
先说结论：ILRuntime不是一个新东西，它已经在我经手的多个中大型项目中稳定跑了好几年，从Unity 2018一直用到了2022。它之所以还有生命力，是因为Lua热更新方案（比如xLua、tolua）需要整个团队接受“用Lua写游戏逻辑”的思维转变，而ILRuntime最大的价值在于热更代码仍然写C#，语法、IDE、类型检查、调试习惯全部保留。对团队来说，学习成本低到可以忽略，特别是对于已经用C#写惯了核心逻辑的团队，这几乎是唯一不需要改变写代码方式、又能上线的热更新方案。
2. ILRuntime的底层工作方式：为什么它能做到“没有做不到”又“处处受限”
2.1 先搞清楚一个反直觉的问题：C#不是编译成机器码吗，为什么还能被解释执行
很多第一次接触ILRuntime的人会有一个疑惑：C#代码在Unity里不是编译好了吗，怎么还能在运行时被读出来、被解释执行？
这就需要先理解C#的编译产物。你用C#写的源码，经过编译器编译后，生成的并不是最终机器码，而是一种叫**IL（Intermediate Language，中间语言）**的东西。IL就是C#的“汇编”，它面向的是CLR（Common Language Runtime，公共语言运行时）。平时Unity在真机上跑游戏，是由Mono或者IL2CPP把这份IL转换成机器码来执行。Mono支持运行时把IL即时编译成机器码（JIT），IL2CPP则是把IL转成C++再编成机器码（AOT），iOS平台走的就是IL2CPP的AOT路线。
但AOT有个死穴：它在编译时就把所有代码都翻译成了机器码，运行时只能执行预先编译好的方法，不允许“中途再来一个新的DLL并让它转成机器码”。所以iOS环境下，你没法运行时加载一个外部DLL然后正常执行——这一下就卡死了热更新的路。
那Lua为什么能热更？因为Lua本质上是解释型语言，它的解释器是提前编译好的机器码，运行的时候Lua脚本作为数据被解释器读取、解析、执行，整个过程不需要JIT，所以不违反iOS的限制。
ILRuntime的思路和Lua一样：它自己实现了一套IL解释器，也就是把之前由系统CLR负责的工作，用纯C#自己实现了一遍。ILRuntime读取热更DLL里的IL指令，用一个用C#写就的虚拟机逐条解释、执行这些指令。这样系统层面看到的只是ILRuntime这个程序集里的C#代码在跑，它不会去执行什么外部动态代码，所以iOS完全管不着。
2.2 托管栈切换机制：ILRuntime内部如何执行你的方法
如果你真的去读ILRuntime源码，或者看它的调用链，会发现实现里有一个最关键的概念叫托管栈（Managed Stack）。普通C#方法跑起来时，线程上有系统分配的调用栈，参数、局部变量、返回地址都在栈上。ILRuntime解释执行一个热更方法时，它不可能借用系统的调用栈，而是在托管堆上维护一个对象栈，所有热更方法的参数、局部变量、返回值都压在这个对象栈上。
当一个热更方法调用另一个热更方法时，ILRuntime会做“栈帧切换”。假设热更方法A调用热更方法B，ILRuntime先把上下文保存，然后切换到B的栈帧，把B需要的参数从栈上取出来传给B的解释执行逻辑，B执行完后再把返回值压到A的栈帧上。这个过程叫做托管栈与CLR栈的切换，也是ILRuntime性能开销的主要来源之一。
这也是为什么ILRuntime在官方文档和社区里一直强调：尽量减少跨域调用（热更代码与主工程代码互相调用的次数）。因为每发生一次跨域调用，就要做一次完全的栈切换、安全检查、数据类型转换，开销远比热更内部的方法调用大得多。这个点在做性能优化的时候非常重要，后面的章节我会专门给出优化套路。
2.3 值类型与引用类型：在解释器世界里，一切都要按“约定”来
ILRuntime对值类型（比如自定义的struct）的处理，远超你对“性能开销”的预期。原因是：解释器里所有变量都当作对象来管理，一个int、一个bool、一个Vector3，在解释器里都是以对象形式存在的。每进行一次赋值、运算、装箱、拆箱，都涉及对象的创建或转换。因此热更代码里如果大量使用int、float、Vector3的频繁运算，性能会明显劣于主工程代码。
举个例子，你在热更代码里写一个循环，循环1000次，每次做向量点乘和叉乘，如果用Vector3结构体进行运算，ILRuntime中每步都会产生中间对象，导致GC频繁触发。实测下来同一段纯计算逻辑，在热更里的耗时可能是主工程的5到20倍。但如果这段代码是放在Update里每帧跑，长期下来会严重影响帧率。
所以，从架构一开始，就要约定一套性能铁律：高频计算的核心循环放主工程，热更层只负责逻辑组织和业务流转。这不是偷懒，而是ILRuntime设计上的必然取舍——它在开发效率和性能之间选择了前者，你就得把性能敏感的代码放到主工程里去兜底。
2.4 同源CLR与跨域机制：热更代码怎么调到主工程代码
ILRuntime最大的一个隐藏优势是热更代码和主工程代码属于同一个语言体系。热更DLL里直接可以声明主工程里的类、调用主工程里的静态方法、访问主工程的组件，只要你通过特定的方式把类型“注册”给ILRuntime就能做到。这个注册过程很直接：初始化ILRuntime环境时，调用其中一个重载方法来加载所有你需要热更代码访问的程序集。
具体来说，主工程暴露给热更层的类型，需要在AppDomain初始化后，通过domain.LoadAssembly加载热更DLL，再通过domain.RegisterCrossBindingAdaptor注册“跨域继承适配器”（涉及热更类继承主工程类或者实现主工程接口的情况），如果是纯调用主工程类，通常不需要额外注册。委托则需要逐个注册，否则在热更代码里把lambda传给主工程事件时，会直接抛异常。
为什么会这样设计？因为跨域调用涉及类型检查、参数转换、返回值转换，解释器不可能自动猜测你主工程里那些具体的委托类型和参数类型，必须你显式告诉它“哪个委托对应哪个热更方法”。很多新手在这里踩坑，报了奇怪的“Delegate not registered”错误，其实就是漏了委托注册。
3. 接入ILRuntime到Unity项目的完整实操流程
3.1 下载与安装：从哪获取、怎么放进项目
ILRuntime目前是开源的，作者一直在维护，从码云或GitHub上都能找到源码仓库。有两种接入方式，我分别说下：
第一种是直接下载源码包，把ILRuntime文件夹整体放进项目的Assets/Plugins目录。这种方式适合你需要修改ILRuntime源码来满足自定义需求的场景。比如有些团队会给ILRuntime加上自己的调试日志、性能监控埋点，甚至修改解释器的一些行为，那就必须用源码方式。
第二种是用Unity Package Manager添加Git地址依赖，或者直接拷贝官方release的.unitypackage包导入。这种方式适合快速集成，官方包会包含必要的运行时库和编辑器扩展，配置简单很多。我一般建议第一次接入的人用官方release包，等跑通整个流程了，有需要再换源码方式。
无论哪种方式，关键点是在Assets目录下不要乱放，建议单独建一个Plugins/ILRuntime目录，这样不会跟项目里其他插件冲突，也方便后续升级替换。
3.2 初始化ILRuntime运行时环境：三行代码跑起来
ILRuntime的使用并不复杂，核心就是一个ILRuntime.Runtime.Enviorment.AppDomain对象。我们一般把它做成单例，在游戏启动时初始化一次。基础代码如下：
using ILRuntime.Runtime.Enviorment; public class ILRuntimeManager : MonoBehaviour { public static AppDomain Domain { get; private set; } void Awake() { Domain = new AppDomain(); var dllBytes = LoadHotfixDllFromRemoteOrLocal(); var pdbBytes = LoadHotfixPdbBytes(); // 可选，用于调试和异常栈还原 using (var fs = new MemoryStream(dllBytes)) using (var ps = new MemoryStream(pdbBytes)) { Domain.LoadAssembly(fs, ps); } // 注册跨域继承适配器 // Domain.RegisterCrossBindingAdaptor(new MyMonoBehaviourAdapter()); // 注册委托 // Domain.DelegateManager.RegisterMethodDelegate<System.String>(); // 进入热更入口 Domain.Invoke("Hotfix_App", "Main", null); } }那段代码里的LoadAssembly是核心动作，它把热更DLL读入AppDomain的内存结构里。注意第二个参数是PDB文件流，通常建议带上PDB，这样ILRuntime能在异常时将IL指令映射回源码行号，排错会轻松很多。
Invoke("Hotfix_App", "Main", null)的意思是：在热更DLL里找到Hotfix_App这个类型，调用它的静态方法Main，参数列表传null。这是热更代码的统一入口，你在热更工程里写好这个类这个方法，主工程启动时调过来，热更世界就开始了。
有个细节提醒一下：如果你走的是iOS平台，热更DLL和PDB文件不会打进包里，它们是作为“数据文件”存放在服务器上的，启动时下载到本地再加载。Android上则可以灵活处理，看你的版本策略。
3.3 创建热更工程：程序集划分、引用关系和编译目标
ILRuntime热更工程可以是一个独立的.NET类库工程，也可以直接放在Unity工程里作为Editor编译的DLL来生成。我见过最多的做法是：在Unity项目旁边建一个单独的C#工程，专门写热更代码，编译生成DLL后复制到Unity项目的某个目录（比如Assets/StreamingAssets或服务器资源目录）。
关键是热更工程怎么引用主工程代码。假设主工程叫Assembly-CSharp，热更工程引用了主工程程序集，那么在编译热更DLL时，它会把主工程的类型引用记录在DLL的元数据里。ILRuntime在加载时，通过LoadAssembly加载的只是热更DLL本身，但它有一个可以手动设置的程序集引用列表。在初始化时，你需要主动把主工程程序集交给ILRuntime，让它知道这些类型存在：
Domain.LoadAssembly(dllStream, pdbStream); // 手动添加主工程程序集引用 var mainAssembly = typeof(GameRoot).Assembly; Domain.LoadAssembly(mainAssembly);这是很多项目第一次接入时遗漏的点。如果热更代码里直接用了主工程的类型，但没把主工程程序集加进来，调用时会出现类型解析失败。可能报错信息不一定直接，但从经验看，多半是“Can't find Type”或“Type is not loaded”。
另外，热更工程的编译目标建议选择.NET Standard 2.0，这样在主流的Unity版本下都能兼容。不要选太旧或者太激进的框架目标，否则ILRuntime在解析某些IL指令时可能会有兼容问题。
3.4 生成CLR绑定：不生成就等着性能爆炸吧
CLR绑定是什么？它解决的核心问题，是ILRuntime在调用主工程非热更方法时，如何避免全反射。如果没有CLR绑定，ILRuntime会通过反射去找到主工程方法并调用，虽然功能上能工作，但性能会被反射拖得很惨。在一个战斗系统中，每一帧可能要调用几十次主工程方法，如果都是反射调用，游戏直接没法玩。
官方提供了CLR绑定生成器，在Unity编辑器菜单里能找到“ILRuntime -> 生成CLR绑定代码”。它会扫描你的主工程程序集，找出所有可能被热更代码调用的类型，然后生成一系列静态的绑定代码。这些代码会走一个快速通路，绕过反射，直接调用方法。
生成时机要记清楚：每次主工程代码有改动（新增方法、改方法签名、新增类等），都需要重新生成CLR绑定。否则你新增的方法在热更里调用时，ILRuntime找不到绑定，就会退回反射，甚至直接报错。
另外，官方还提供了一个“CLR绑定精简”的选项，可以把未使用到的CLR类型排除掉，减少打包体积。我的经验是：先全量生成确保没问题，再逐步精简，不要一上来就手工配置类型列表，很容易漏掉关键类型。
4. 我踩过的坑：ILRuntime项目实战中的高频问题与解决方案
4.1 异常快照和栈信息丢失：线上崩溃怎么定位
这是ILRuntime使用中最让人痛的一点。热更代码抛出异常时，默认只能看到十分简略的栈信息，稍微复杂一点的调用链，根本无法定位是哪个方法出的问题。官方其实提供了解决方案：注册一个OnCLRException和OnILRuntimeException事件，把异常记录下来。同时，加载PDB时，ILRuntime能支持把IL指令转成源码行号，你需要额外初始化一下DebugService。
我自己项目里的做法是：做一个全局异常日志系统，把热更层异常和主工程异常分开记录。每次上报时把完整的异常信息、热更代码版本号、客户端版本号一起提交到后台。热更代码版本号特别重要，不然线上有异常，你根本不知道用户跑的是哪一版热更逻辑。
另外一个坑是：异常对象本身也可能涉及跨域类型转换，所以捕获到异常后不要直接打印e.StackTrace，很可能它只是托管栈内部信息。正确姿势是：
domain.DebugService.ResolveILException(e, out var ilStackTrace);这一步能拿到带源码文件名的堆栈，排查效率会大幅提升。
4.2 委托和事件没有注册：表现为“莫名诡异”的崩溃
跨域委托是高频踩坑点。典型场景：热更代码向主工程某事件注册了一个方法，比如Button.onClicked.AddListener(MyHandler)。正常编译能过，热更也能跑，但一旦真机运行，点击按钮的瞬间直接崩溃，报一个“Delegate not registered”或者“Method not found”。
原因在于：UnityEngine.Events.UnityAction这个委托，ILRuntime必须在初始化时知道“热更里定义的无参方法，可以转换成UnityAction委托”。这需要显式注册：
Domain.DelegateManager.RegisterMethodDelegate<UnityEngine.Events.UnityAction>();更麻烦的是带参数的委托，例如UnityAction<bool>、UnityAction<int, string>，需要对应注册RegisterMethodDelegate<bool>()、RegisterMethodDelegate<int, string>()。
我的建议是：用一个集中的静态类做所有委托注册，把所有可能用到的委托类型全部列出来注册一遍。虽然多写几句，但能避免线上漏注册的噩梦。
4.3 跨域继承必须用适配器：热更MonoBehaviour写法的特殊规则
另一个大坑是热更类继承MonoBehaviour。你在热更DLL里写一个类，继承MonoBehaviour，然后试图用AddComponent<T>()把它加到GameObject上，你会发现根本不对。因为热更类不是真正的MonoBehaviour派生类，Unity引擎无法直接实例化并管理它。
官方的方案是跨域继承适配器（CrossBindingAdaptor）。你需要写一个主工程里的适配器类，它继承MonoBehaviour，同时实现一个接口，在接口方法里把调用转发到热更类的对应方法。然后热更类要实现这个接口。这样Unity管理的是适配器组件，适配器再把生命周期事件抛给热更类。
具体代码量不小，但这是绕不过去的。我的经验是：在热更工程里不要直接继承MonoBehaviour来写业务逻辑，而是把逻辑放到一个普通的C#类里，由主工程提供一个“持有者”组件来驱动。这样能大幅减少适配器的编写量。例如：
public class HotfixBehaviourHolder : MonoBehaviour { public object HotfixObject { get; set; } void Awake() { HotfixObject?.Invoke("Awake", null); } void Update() { HotfixObject?.Invoke("Update", null); } }然后在热更侧写一个普通类，由这个持有器在Awake时创建并赋值。这套模式在几个项目里都验证过，稳定、简单、适配器少，强烈推荐。
4.4 泛型方法的限制：AOT环境下编译不过去
C#泛型是很常用的特性，但在ILRuntime + iOS这种AOT环境下，泛型方法会被卡脖子。因为泛型方法的具体实现需要JIT来生成，而iOS上不允许。例如热更代码里写var list = new List<MyHotfixClass>()，理论上可以用，但如果涉及泛型方法的跨域调用（例如List<T>.FindAll传入一个热更委托），问题就来了。经常会看到“ExecutionEngineException”或“Attempting to JIT compile method”的报错。
解决办法有两种。第一种，对可能用到的泛型类型组合，在主工程里显式实例化一次（提前AOT），这叫AOT泛型预编译。第二种，尽量避免跨域的泛型委托传递。
在多个项目中，我摸索出的原则是：在热更代码里尽量不用泛型委托，遇到集合操作时，自己写循环而不是依赖LINQ和泛型高阶函数。虽然多写几行，但能规避一类很难排查的线上崩溃。你要真忍不住用LINQ，至少确认该调用的LINQ方法不涉及跨域委托传递。
5. 性能优化：如何让ILRuntime从“能跑”到“跑得稳”
5.1 减少跨域调用的数量级，比优化调用本身更有效
前面提到，跨域调用的开销主要在栈切换和类型检查。所以性能优化的第一条原则就是减少调用次数。举例：一个战斗单位每帧要检查Buff剩余时间、刷新状态、更新位移，如果这些逻辑都在热更层，而每帧又频繁调用主工程的Time.deltaTime、Transform.position，几百个单位一跑，帧率直接崩。
比较好的做法是：在热更层里把数据拉取做成批量一次性获取。比如主工程提供一个方法GetAllUnitsState()，一次性返回一个数组结构，热更层拿到数据后做本地计算，而不是每帧循环里调用几十次跨域方法。
更极端一点的优化是：把战斗核心逻辑（碰撞检测、伤害计算、寻路）整体放主工程，热更层只负责战斗事件的触发、技能的流程控制、Buff表的配置读取。这样可以保证高频部分跑原生编译代码，热更逻辑大部分时间是在低频率的决策层运作。性能会非常稳定。
5.2 值类型与装箱拆箱的隐形开销：一次循环就能拖垮帧率
ILRuntime性能优化的第二个重点，是值类型处理。热更代码里赋值一个Vector3、计算一个Quaternion，在解释器里开销远大于主工程。尤其是大量使用装箱（boxing）的场景——比如把int塞进ArrayList，或者把一个struct当object传参——每一次装箱都会创建堆对象，触发GC。
我建议在热更工程里做以下约束：
- 使用自定义的轻量数学结构体（不含复杂继承和虚函数），或者直接把向量运算封装到主工程的方法里；
- 避免在热更代码里使用
object或者非泛型集合保存值类型； - 对热更代码中的循环体做严格Review，把每次循环的装箱次数控制在个位数。
如果实在无法避免某些热点逻辑驻留热更层，一个实用技巧是：用主工程提供的静态方法去处理这个热点逻辑，热更层只负责传参、读取结果。相当于把热更的短板，借主工程的性能来补。
5.3 使用Delegate与List的陷阱：热更里尽量不要做重负载容器操作
在热更代码里，List<T>、Dictionary<K,V>的读写效率其实还行，但如果这个容器在主工程和热更之间反复传递，问题就会放大。尤其是List<UnityEngine.Object>这种容器，热更代码遍历它并调用每个元素的方法，会触发大量的跨域调用。
一个折衷方案是：主工程维护对象的原始容器，提供整体操作入口，热更层只传递ID或索引。这样热更层拿到的是int数组之类的纯值类型数据，跨域时开销可控。项目组在引入这个约定后，战斗单位的数量从200提升到500，帧率反而更稳定了。
5.4 内存管理与GC压力：解释器的对象膨胀问题
ILRuntime解释器的一个特性，是热更代码运行时会产生大量临时对象，GC压力比原生C#更大。如果热更代码里频繁拼接字符串、使用LINQ延迟查询、大量创建匿名对象，那么游戏运行一段时间后，内存堆会明显增长。特别是低端安卓机，GC Alloc曲线一旦上去，掉帧和卡顿很容易出现。
我实践的优化套路是：
- 热更代码里的字符串拼接改用
StringBuilder，并且尽量复用； - 数据表读取后，把数据缓存成热更侧的结构体数组，避免每次战斗都重新解析;
- 避免在Update里做任何热更侧的对象创建；
- 对热更侧对象实现一个简单的对象池，尤其是弹幕、飘字、特效控制类对象。
这里想额外提醒一个点：不要以为热更侧产生的对象会在热更卸载时自动释放干净。ILRuntime AppDomain实例如果一直存活，堆上的对象只能等GC自然回收。因此设计上尽量避免重复创建和销毁热更AppDomain，一次启动，服务整个生命周期就好。
6. 工程组织与版本管理：热更项目长久稳定运行的基石
6.1 程序集划分：哪些代码该放热更，哪些不该放
接ILRuntime之前，最先要想清楚的是热更边界。放热更的代码，应该是迭代频繁、逻辑复杂、发布后容易出问题的模块；不放热更应该的性能敏感代码和基础框架。我一般遵循下面的原则：
- 放热更：UI界面逻辑、活动玩法、关卡配置逻辑、任务系统、新手引导、商城逻辑、技能流程；
- 不放热更：寻路库、物理相关逻辑、渲染管线相关、网络底层框架、资源管理框架、核心战斗数值计算高频部分、以及各种需要AOT友好的公共基础库。
这个划分不是绝对的，但它决定了你项目的性能基调和维护成本。我见过一个项目把大量战斗AI逻辑放到热更里，结果每次版本更新都要优化一版性能，后来重构了一次，把AI决策放主工程，表现立刻稳了。在架构评审阶段就要反复强调这个边界，免得业务侧代码越写越深入。
6.2 热更版本的兼容性：无脑强制更新不是好选择
热更版本管理非常容易翻车。假设线上已经有一些用户在跑Hotfix v10，你发布了v11，但v11里忘记了兼容旧的存档数据结构，那么这批用户更新后可能无法读取存档，被迫删档重来。
我的做法是把热更代码和配置数据相互独立管理：
- 热更DLL版本决定逻辑行为；
- 配置表版本决定数值表现；
- 客户端主工程版本决定底层能力。
每次发版，后台记录这三者之间的最低兼容组合。在启动时客户端上报自己的版本组合，服务器返回“可用热更包列表”，如果有不可兼容的情况，强制走整包更新流程。这样能最大程度避免“DLL新版配旧表”这类诡异问题。
6.3 测试与灰度发布：热更包也需要流程
热更虽灵活，但发布前依然要建立一套自检流程。至少应该包含下面几步：
- 本地构建热更DLL后，用一个干净的模拟环境跑一遍核心冒烟用例；
- 用旧存档数据加载新热更包，检查兼容性；
- 在内部测试机上验证iOS和Android两种平台的表现；
- 发布到灰度环境，观察一段时间的异常上报率。
尤其要注意热更包的加载顺序和下载失败策略。如果热更下载失败，用户进入游戏后会跑旧逻辑，很多团队忘了给旧逻辑做“版本不匹配”的UI提示，造成用户莫名其妙。建议启动时做一个阻塞式更新提示，热更包下载完成后才进入登录流程。
7. 常用工具与调试技巧：ILRuntime日常开发生存指南
7.1 使用DebugService获取堆栈和源码映射
市面上不少团队接入ILRuntime后，遇到异常只看到一行“ILRuntime: Exception”就没下文了，排查效率极低。实际上DebugService提供了比较完整的能力。接入后你可以这样做：
domain.DebugService.OnDebugMessage += (msg) => UnityEngine.Debug.Log(msg);全局捕获ILRuntime调试信息。当异常发生时，优先使用ResolveILException还原热更侧堆栈，把它和CLR堆栈合并打印。这样处理过一次后，你基本能像调试纯C#项目一样定位热更代码的问题。
7.2 符号文件（PDB）必须保留，但发布前可以剥离
PDB文件对调试很重要。如果你没有随DLL一起加载PDB，那么ILRuntime抛异常时拿不到方法名和行号，相当于退回“盲修”状态。在开发期和测试期，务必要让构建流程产出并加载PDB。
但发布到线上的热更包，PDB却可以去掉，有两个原因：一是体积，PDB包含大量调试符号，能撑大包体；二是反编译风险，携带原始行号和方法结构会降低DLL被混淆后的安全性。建议构建线上包时单独把PDB提交到故障排查平台，客户端只加载不携带PDB的DLL。
7.3 用Mono的调试器还是自研日志？我的建议是组合使用
ILRuntime官方支持Mono的调试协议，可以在编辑器里像调试普通C#一样打断点调试热更代码。但实际项目里，因为热更代码是运行时加载的，断点有时会不灵，特别是发布了热更包后，用户运行的代码和你本地调试的代码版本不一致，很难复现问题。
所以我更推荐自研日志体系。在热更代码的关键路径里埋结构化日志点（包括热更版本号、调用参数、返回值、耗时），这些日志和主工程日志统一上抛到后台。线上问题发生时，拉日志看关键路径，比远程断点效率高得多。ILRuntime本身不限制你的日志方案，只要你把输出串接到统一的日志系统即可。
7.4 混淆与安全：保护热更DLL不被轻易解包
热更DLL直接暴露在客户端资源目录里，安全性天然弱于主工程DLL。如果游戏敏感（比如包含排行榜竞技或者抽卡逻辑），建议做一层混淆处理。ILRuntime本身和混淆工具的兼容性还算不错，前提是不要混淆ILRuntime自身的核心类，否则解释器解析会出问题。
我常用的做法是：
- 对热更DLL里的业务类和方法名做混淆，但不混淆ILRuntime需要反射调用的入口；
- 入口方法（比如Main）保持名字不变，用一个只有服务器知道的随机入口字符串，配合服务器下发入口方法名；
- 关键数值逻辑不要写在客户端本地，而是放到服务器校验。
简单说，热更DLL只是防君子不防小人，真要对抗专业破解，光靠混淆远远不够，重要逻辑必须放服务端。
8. 我的最终建议：ILRuntime适合什么项目，不适合什么项目
说了一堆实操，最后聊聊选型。如果你做一个面向iOS和Android的Unity商业游戏，团队以C#为主力语言，业务迭代频繁，需要每周甚至每天热更，那么ILRuntime是一个很适合的方案。它能让你在C#舒适区内拿到热更新能力，团队不需要切换语言，不需要额外招聘Lua开发者，CI流程也能很快构建热更包。
不建议用ILRuntime的场景也有：如果你的项目是纯单机游戏、不需要频繁更新逻辑，或者你的核心战斗逻辑占总代码量90%以上、几乎全部是高频计算，那么即使技能上能塞进热更，你也会为了性能付出巨大优化成本。这种项目要么不上热更，要么干脆用支持更轻量化逻辑的脚本方案。
从我个人的盘感来说，ILRuntime最舒服的用法是“主工程做骨架，热更做血肉”。主工程提供稳定、高性能、AOT友好的基础能力，热更层负责让策划和运营能快速改变游戏行为。这样架构既稳又活。运行几个版本后你会体会到：真正让ILRuntime项目跑得好的，不单是解释器本身的性能，而是你团队有没有在工程架构上把这条热更边界划清楚。
如果你刚接触ILRuntime，我建议先不要急着在正式项目里大规模使用，拿一个Demo跑通“主工程调用热更入口、热更调用主工程方法、热更更新逻辑后打包替换”的完整链路，感受一下这套机制的行为模式，再逐步铺开。Lua热更方案的价值我不否认，但ILRuntime在“C#团队”这个语境下，确实是一条被验证过的、值得托付的路线。
