1. 项目概述：为什么热更新是C#项目的“刚需”与“痛点”

在移动端和客户端开发领域，热更新技术早已不是锦上添花，而是决定产品迭代速度和用户体验的“生命线”。想象一下，你的游戏或应用上线后，发现了一个紧急的Bug，或者想快速上线一个节日活动。如果每次都需要用户重新下载几百兆甚至上G的安装包，流失率会有多高？热更新的核心价值就在于，它能让你在不重新发布客户端、不打扰用户的情况下，动态地更新应用的逻辑、界面甚至资源。

对于使用C#和Unity的开发者来说，热更新更是绕不开的话题。Unity官方早期的方案是使用C#的反射和动态加载，但受限于Mono和IL2CPP的AOT（Ahead-Of-Time）编译特性，直接动态加载新的C# DLL在iOS等平台上是行不通的。这就催生了以ILRuntime、HybridCLR（原huatuo）为代表的第三方热更新解决方案。ILRuntime凭借其纯C#实现、轻量级以及对Unity版本良好的兼容性，成为了许多项目的首选。

然而，引入ILRuntime并不意味着高枕无忧。它更像是一把双刃剑：给你带来了热更能力，同时也带来了性能开销、类型转换的“墙”、以及一系列新的调试和部署挑战。很多团队在接入后会发现，热更代码跑是能跑，但时不时卡顿一下，或者出现一些难以理解的类型转换错误，调试起来更是让人头疼。这恰恰就是标题中“热更新难题”所指的核心——如何让热更新在可用、稳定的基础上，进一步做到高效、易维护。

ILRuntime 3.0版本带来了不少底层优化和新特性，但工具再好，也需要正确的“驾驶技巧”。本文将围绕ILRuntime 3.0，结合C#语言特性，深入剖析实现高效热更新的五大核心技巧。这些技巧不是简单的API罗列，而是源于实际项目踩坑后的经验总结，旨在帮你构建一个既灵活又健壮的热更新框架，真正将热更新的价值最大化。

2. 核心技巧一：精心设计热更域与主工程域的通信边界

热更新最核心的设计哲学就是“边界划分”。ILRuntime通过创建一个独立的“热更域”（AppDomain）来运行热更DLL，这个域与主工程的原生域是隔离的。这种隔离带来了安全性和灵活性，但也制造了通信的鸿沟。如何高效、清晰、安全地跨过这道鸿沟，是第一个要解决的难题。

2.1 理解跨域调用的性能本质

首先必须明确一点：所有从热更域调用主工程域（或者反向）的操作，都不是简单的函数调用，而是一次“跨域交互”（Invocation）。这个过程涉及参数的序列化、跨域边界的切换、上下文环境的建立等开销。频繁的、细粒度的跨域调用是性能杀手。

一个常见的反面例子是，在热更的UI逻辑里，每帧都去调用主工程的一个静态方法来获取时间。虽然代码简洁，但每帧的跨域开销累积起来非常可观。正确的做法是，将这种高频调用“批量化”或“代理化”。

2.2 设计高效的通信桥梁：适配器与委托

ILRuntime推荐使用“适配器”（Adapter）来注册跨域继承的接口或类。但仅仅注册是不够的，我们需要设计通信模式。

技巧：使用“委托集群”或“服务门面”来收敛调用入口。

不要在主工程暴露几十个零散的静态方法给热更域。相反，应该创建一个或少数几个“桥接器”类。例如，定义一个IHostService接口在主工程，里面聚合了热更代码可能需要访问的所有功能：资源加载、网络请求、音频播放、游戏数据获取等。

// 在主工程定义 public interface IHostService { GameObject LoadPrefab(string path); void PlaySound(string clipName); PlayerData GetPlayerData(); void Request(string url, Action<string> onSuccess, Action<string> onFail); } // 主工程实现并注册给ILRuntime public class HostServiceImpl : IHostService { ... }

在热更域，你通过ILRuntime获取到这个IHostService的实例（实际上是跨域代理），然后所有操作都通过这个单一的入口进行。这样做的好处是：

1. 接口清晰：热更开发者一目了然地知道他能调用哪些主工程能力。
2. 易于管理：所有跨域调用收敛于一点，便于后期做监控、日志或性能分析。
3. 减少注册量：只需要为这一个接口或少数几个接口生成适配器。

另一个高级技巧是善用委托（Action/Func）。对于回调场景，比如网络请求完成、动画播放结束，直接将Action或Func从热更域传递到主工程域是高效的。ILRuntime 3.0对委托的支持更加完善。但要注意，传递的委托本身也是在热更域定义的，主工程调用它时依然是跨域调用。因此，适用于低频回调，不适用于高频事件。

实操心得：在设计通信接口时，尽量采用“粗粒度”设计。一次调用传递一个结构化的数据对象（比如一个包含了所有需要更新信息的UpdateInfo类），远比为了更新姓名、等级、金币而发起三次调用要高效得多。同时，务必为所有跨域接口和方法编写详细的XML注释，因为热更域的代码智能提示看不到主工程的具体实现，清晰的接口文档至关重要。

2.3 值类型与引用类型的传递策略

参数传递也有讲究。基本值类型（int, float, bool等）的传递开销较小。而字符串（string）和自定义的引用类型对象，在跨域传递时需要进行Marshaling（封送），即在不同域之间复制或转换数据，这会带来额外的GC（垃圾回收）压力和性能开销。

技巧：对于复杂数据，优先考虑使用可序列化的值对象或简单的数据结构。

如果热更域需要频繁向主工程查询一个复杂对象的状态（比如玩家的装备列表），可以考虑在主工程侧提供一个“快照”方法，将装备列表序列化为一个简单的数组或字典（int[],Dictionary<string, int>）再返回。虽然这需要一些转换代码，但避免了将整个复杂的List<Equipment>引用类型进行跨域封送。

反之，从主工程向热更域传递数据时，也可以采用同样策略。ILRuntime 3.0对List<T>,Dictionary<TKey, TValue>等常用泛型容器的跨域支持有所增强，但在性能敏感路径上，手动优化数据格式仍然是值得的。

3. 核心技巧二：优化热更代码的性能与内存管理

热更代码运行在ILRuntime的解释器或JIT（Just-In-Time）编译器上，其执行效率天然低于主工程AOT编译后的本地代码。因此，在编写热更代码时，需要有更强的性能意识。

3.1 警惕热更域内的“性能陷阱”

一些在原生C#中看似平常的操作，在热更域内可能会被放大：

• 频繁的装箱/拆箱：在热更域内，应尽量避免使用ArrayList、Hashtable等非泛型容器，改用List<T>,Dictionary<TKey, TValue>。使用enum时也要注意其底层类型，避免与int混用导致的装箱。
• Lambda表达式与闭包：Lambda会生成匿名类和闭包，在热更域内创建这些对象的开销可能更高。对于高频调用的函数（如Update循环内的判断），考虑将其提取为静态方法或成员方法。
• 字符串操作：大量的字符串拼接（尤其是使用+运算符）会产生大量临时字符串，加剧GC压力。在热更域内，应更积极地使用StringBuilder。

3.2 利用ILRuntime 3.0的性能增强特性

ILRuntime 3.0引入了一些提升性能的配置选项，需要我们主动去利用：

• 增量式GC（Incremental GC）：可以在初始化ILRuntime时开启。它将GC工作分摊到多帧完成，避免单帧因GC导致明显的卡顿。对于性能要求高的游戏，这是一个非常重要的选项。

  var appDomain = new ILRuntime.Runtime.Enviorment.AppDomain(); appDomain.UnityMainThreadID = System.Threading.Thread.CurrentThread.ManagedThreadId; // 启用增量GC appDomain.InitializeIncrementalGC(100); // 参数表示每帧最多分配多少字节后触发增量GC步骤

• 方法内联（Method Inlining）：ILRuntime支持有限的方法内联优化。对于非常小的、频繁调用的热更方法（比如一些属性getter或简单的工具方法），可以尝试通过特性标记来提示运行时进行内联，但效果需要实测，并非总是正向优化。

• 值类型绑定（ValueType Binding）：对于热更域内自定义的struct（值类型），为其注册值类型绑定可以大幅提升其在跨域传递和作为泛型参数时的性能。因为默认情况下，自定义值类型在跨域时会被当作引用类型处理，产生装箱开销。注册绑定后，ILRuntime会以更高效的方式处理它们。

  // 假设热更域有一个 struct MyVector3 appDomain.RegisterValueTypeBinder(typeof(MyVector3), new MyVector3Binder());

3.3 内存泄漏排查：跨域引用的循环依赖

这是ILRuntime项目中最隐蔽的坑之一。由于两个域之间存在交互，可能会意外形成“主工程对象A引用热更对象B，热更对象B又（通过委托或接口）引用主工程对象C，而对象C间接持有A”这样的跨域循环引用。ILRuntime的GC是分域的，这种跨域的循环引用会导致两个域的对象都无法被正确回收，从而引发内存泄漏。

排查技巧：

1. 弱引用（WeakReference）是好朋友：当热更域需要持有主工程对象的引用仅为回调时，考虑在主工程侧将回调保存为弱引用。或者，设计清晰的生命周期管理，在热更模块卸载（如场景切换）时，主动移除所有回调注册。
2. 使用Profiler和日志：Unity Profiler可以查看托管堆内存。如果发现ILRuntime.Runtime.Intepreter.ILTypeInstance或ILRuntime.Runtime.Enviorment.CrossBindingAdaptor等ILRuntime相关类型的对象数量只增不减，很可能存在泄漏。可以在对象的构造函数和析构函数（或Dispose方法）中加日志，跟踪其生命周期。
3. 简化引用关系：审视你的通信接口设计，避免设计出双向的、紧密的耦合。尽量采用单向的、订阅/发布模式的事件系统来解耦。

4. 核心技巧三：构建流畅的开发与调试工作流

热更新代码的调试体验，一直是开发者吐槽的重点。不能像原生代码一样直接断点、单步跟踪，极大地降低了开发效率。ILRuntime 3.0结合现代开发工具，可以搭建出一套相对可用的调试流程。

4.1 实现“编辑即热更”的开发体验

目标是：在Unity编辑器中修改热更C#代码后，能立刻看到效果，无需重启游戏甚至无需重载场景。这需要一套自动化脚本的支持。

核心步骤：

1. 独立的C#项目：将热更代码放在一个独立的 .NET Standard 2.0 或 .NET Framework 类库项目中（例如GameHotfix），而非直接放在Unity的Assets/Scripts目录下。这保证了编译环境和主工程分离。
2. 自动化编译与加载：编写一个Editor工具，监听热更项目DLL的输出路径。当检测到DLL更新时（使用FileSystemWatcher或每次编译后手动触发），自动执行以下操作：
   • 将新的DLL和PDB（调试符号文件）复制到Unity项目的StreamingAssets或特定目录。
   • 调用一个游戏内的热更加载管理器，重新加载新的DLL。
   • 热更管理器在接收到重载指令后，释放旧的AppDomain，创建新的，重新初始化所有热更模块。

// 简化的编辑器工具示例 [UnityEditor.InitializeOnLoadMethod] public static void RegisterAutoReload() { UnityEditor.EditorApplication.playModeStateChanged += state => { if (state == UnityEditor.PlayModeStateChange.EnteredPlayMode) { // 进入播放模式时，启动文件监听 StartWatchingHotfixDLL(); } }; } static void StartWatchingHotfixDLL() { var watcher = new FileSystemWatcher(Path.GetDirectoryName(HotfixDllPath)); watcher.Filter = Path.GetFileName(HotfixDllPath); watcher.NotifyFilter = NotifyFilters.LastWrite; watcher.Changed += (s, e) => { UnityEditor.EditorApplication.delayCall += () => { Debug.Log("检测到热更DLL变化，正在重载..."); // 通知游戏内的热更管理器重载 HotfixManager.Instance.Reload(); }; }; watcher.EnableRaisingEvents = true; }

4.2 利用Visual Studio或Rider进行源码级调试

ILRuntime支持使用Visual Studio或JetBrains Rider进行源码级调试，前提是生成了正确的PDB文件并进行了配置。

关键配置点：

1. 生成调试信息：确保热更C#项目在编译时生成“便携式PDB”（Portable PDB）或“完整PDB”。
2. 加载PDB：在ILRuntime加载DLL时，同时加载同名的PDB文件。

   using (var fs = new FileStream(dllPath, FileMode.Open, FileAccess.Read)) using (var pdbFs = new FileStream(pdbPath, FileMode.Open, FileAccess.Read)) { appDomain.LoadAssembly(fs, pdbFs, new ILRuntime.Mono.Cecil.Pdb.PdbReaderProvider()); }

3. 启动调试服务器：在Unity中，初始化ILRuntime后，启动调试服务并指定一个端口。

   appDomain.DebugService.StartDebugService(56000); // 端口号可自定义

4. IDE附加调试器：在Visual Studio中，选择“调试” -> “附加到进程”，找到Unity编辑器进程，选择“使用Unity调试器连接”或“托管（CoreCLR）”，并填入localhost:56000。在Rider中，过程类似，通过“运行” -> “附加到进程”来完成。
5. 设置符号文件路径：在IDE中，确保符号文件（PDB）的搜索路径包含PDB文件所在位置。

完成这些步骤后，理论上就可以在热更项目的源码中设置断点，命中断点时，Unity会暂停，IDE会跳转到对应的源代码行。实测心得：这套流程在Windows+Visual Studio环境下相对稳定，但在Mac或使用Rider时可能会遇到一些连接问题。调试性能也不如原生代码流畅，但对于排查复杂逻辑问题，这仍然是不可或缺的手段。

注意事项：调试服务会带来一定的运行时开销，因此仅在开发阶段开启。发布版本务必关闭调试服务。另外，确保热更项目的源码路径在团队内是统一的（例如使用相对路径映射），否则PDB中的源码路径对不上，会导致调试器找不到源文件。

5. 核心技巧四：设计模块化与可卸载的热更架构

热更新不应该是一个“铁板一块”的巨大DLL。良好的架构应该支持按功能模块进行热更，并且支持模块的动态加载和卸载，这对于大型项目管理内存和更新粒度至关重要。

5.1 基于接口与抽象的热更模块设计

为每个热更功能模块定义一个清晰的接口（或抽象基类），这个接口定义在主工程。热更DLL中的模块实现这些接口。

// 在主工程定义 public interface IHotfixModule { string ModuleName { get; } void Initialize(); void Update(float deltaTime); void Shutdown(); } // 在热更工程实现 public class ActivityModule : IHotfixModule { public string ModuleName => "Activity"; public void Initialize() { /* 初始化活动数据、UI */ } public void Update(float deltaTime) { /* 更新活动倒计时等 */ } public void Shutdown() { /* 清理活动相关资源、注销事件 */ } }

主工程的热更管理器维护一个Dictionary<string, IHotfixModule>，负责模块的加载、初始化和卸载。这样，你可以通过配置文件来决定本次更新需要下载和加载哪些模块，实现增量更新。

5.2 实现安全的模块卸载

模块卸载的关键在于资源的清理和引用的解除。仅仅从字典里移除模块实例是不够的，必须确保模块的Shutdown方法被正确调用，并且该模块注册的所有事件监听、持有的所有跨域引用（尤其是对主工程对象的引用）都被妥善释放。

安全卸载检查清单：

1. 事件与委托：模块在Initialize中订阅了哪些主工程或全局的事件？必须在Shutdown中一一取消订阅。
2. 定时器与协程：模块内部启动的定时器或模拟的协程（因为ILRuntime不支持Unity原生的协程，通常需要自己实现一个调度器）必须被停止和清理。
3. UI与资源：模块创建的游戏对象（UI面板、特效等）必须被销毁（GameObject.Destroy）。加载的资源（通过主工程接口加载的）是否需要卸载？需要根据项目资源管理策略决定。
4. 静态字段：模块中的静态字段是“全局”的，不会因为实例被回收而清除。必须在Shutdown中将其显式置为null，否则会导致内存泄漏和状态污染。

5.3 模块间的通信解耦

热更模块之间也应避免直接引用，否则会形成紧耦合，不利于独立更新。推荐使用一个轻量级的、位于热更域内部的消息总线（Message Bus）或事件中心。

// 热更域内的事件中心简化版 public class HotfixEventCenter { private static Dictionary<string, Action<object>> eventTable = new Dictionary<string, Action<object>>(); public static void AddListener(string eventName, Action<object> handler) { ... } public static void RemoveListener(string eventName, Action<object> handler) { ... } public static void Trigger(string eventName, object data = null) { ... } }

模块A触发HotfixEventCenter.Trigger("PlayerLevelUp", level)，模块B监听"PlayerLevelUp"事件并做出反应。这样，模块A和B互不知晓对方的存在，实现了完全解耦。这个事件中心本身应该是简单且稳定的，作为热更框架的基础设施的一部分。

6. 核心技巧五：建立完善的打包、测试与发布流程

热更新代码最终要交付给玩家，因此其打包、测试和发布流程必须可靠且自动化，任何手动环节都是潜在的事故点。

6.1 自动化构建流水线

将热更DLL的编译、打包、上传集成到CI/CD（持续集成/持续部署）流水线中。以Jenkins或GitLab CI为例：

1. 编译：拉取热更代码仓库，使用dotnet build或msbuild编译出目标DLL。
2. 版本管理：为生成的DLL生成一个唯一的版本号（如基于Git提交哈希、构建时间戳）。这个版本号需要写入一个配置文件（如hotfix_version.json），并和DLL一起打包。
3. 差异比对与生成补丁（高级）：对比本次构建的DLL与线上最新版本的DLL，使用二进制差分算法（如bsdiff）生成一个体积更小的补丁包，而不是每次都让玩家下载完整的DLL。
4. 上传：将版本文件、DLL（或补丁包）上传到你的资源服务器（CDN）。
5. 通知：更新游戏服务器的版本配置，或者触发一个通知，让客户端知道有新热更可用。

6.2 多层次测试策略

热更代码的测试需要比原生代码更严格，因为它直接面向线上环境。

• 单元测试：在热更C#项目中，使用NUnit或xUnit编写单元测试，对核心业务逻辑进行测试。这部分测试可以在编译服务器上自动运行。
• 集成测试（在编辑器内）：在Unity编辑器中，编写Play Mode测试用例。这些用例会启动游戏，加载热更DLL，并模拟玩家操作，测试热更模块与主工程的集成是否正常。Unity Test Runner可以很好地组织这类测试。
• 兼容性测试：这是最易被忽略的一环。确保新版本的热更DLL能够与旧版本的主工程客户端兼容。因为玩家可能不会立刻更新App。测试时，需要用当前发布包的主工程，去加载最新开发中的热更DLL，验证所有功能是否正常。反之，也要用最新的主工程（开发中）去加载线上正在运行的热更DLL，确保主工程更新不会破坏现有热更功能。
• 回滚测试：模拟热更失败或发现严重Bug时，回滚到上一个热更版本的过程是否平滑。客户端的热更管理器需要能识别版本、下载旧版本DLL并安全降级。

6.3 设计健壮的热更失败处理机制

网络可能中断，下载的DLL可能损坏，新DLL可能存在致命错误。客户端必须能优雅地处理这些失败。

1. 版本验证与重试：下载DLL后，立即校验其MD5或SHA1哈希值，与服务器下发的哈希进行比对。不一致则删除重下，可设置最大重试次数。
2. 沙箱加载与验证：不要直接加载下载的DLL到主运行环境。可以创建一个临时的、独立的AppDomain来尝试加载和初始化这个DLL，执行一些简单的冒烟测试（例如调用一个预定义的测试接口）。如果在这个过程中发生任何未处理的异常，则判定该DLL不安全，放弃加载，并回退到旧版本。
3. 异常隔离与恢复：即使DLL加载成功，在运行中也可能会抛出未捕获的异常。需要在ILRuntime的入口点（如热更模块的Update调用）包裹try-catch。一旦捕获到致命异常，应记录错误、通知服务器，并尝试将游戏状态恢复到安全点（例如，关闭所有热更UI，回到主菜单），避免游戏崩溃。
4. 强制更新与降级策略：如果某个热更版本是强制性的（例如修改了与服务器通信的协议），而玩家客户端无法成功更新，则应阻止其进入游戏，并提示前往应用商店更新完整包。同时，服务器端需要维护一个客户端最低热更版本号，以支持版本控制。

7. 常见问题与排查技巧实录

在实际使用ILRuntime进行热更新的过程中，总会遇到一些“诡异”的问题。下面记录了一些典型问题及其排查思路，希望能帮你快速定位。

7.1 类型转换异常：InvalidCastException

这是最常见的问题之一，通常发生在跨域传递对象时。

• 症状：InvalidCastException: Cannot cast from source type to destination type.
• 排查：
  1. 检查适配器：首先确认发生转换的类型是否在主工程正确注册了适配器（RegisterCrossBindingAdaptor）。不仅包括直接使用的类，还包括其基类或接口。
  2. 检查继承关系：热更域中的类继承自主工程的类时，必须使用: CrossBindingAdaptorType的形式。确保没有写错。
  3. 检查泛型：泛型类的跨域使用尤其容易出错。确保泛型参数是允许的基本类型或已注册的类型。有时需要为特定的泛型组合注册适配器。
  4. 使用CLRRedirection：对于某些系统API（如UnityEngine.Debug.Log的重定向），如果配置不正确，也可能导致内部类型转换失败。

7.2 性能热点定位：热更代码卡顿

感觉游戏在热更逻辑执行时卡顿。

• 排查工具：

  1. Unity Profiler：这是第一选择。在Profiler的CPU使用率面板中，注意查看ILRuntime相关的条目，如ILRuntime.Invocation、ILRuntime.Runtime.Intepreter.ILIntepreter.Execute。如果它们占用过高，说明存在高频或复杂的跨域调用/热更域内解释执行。
  2. 自定义性能分析：在代码中关键路径加入时间戳，使用System.Diagnostics.Stopwatch来测量热更域内特定函数的执行时间。
  3. ILRuntime性能分析器：ILRuntime自带一个简单的性能分析工具，可以统计每个热更方法的调用次数和耗时。在开发阶段开启它，可以帮助你找到最耗时的热更函数。

     appDomain.StartProfile(); // ... 运行一段游戏逻辑 var profileResult = appDomain.EndProfile(); // 输出或分析profileResult

• 优化方向：根据Profiler结果，如果是跨域调用频繁，则应用技巧一进行通信收敛。如果是热更域内某个逻辑复杂的方法耗时高，则考虑用技巧二进行优化，或者评估是否可以将该函数迁移到主工程（如果它不常变更）。

7.3 内存泄漏排查：对象不释放

怀疑热更相关对象没有正常释放，内存持续增长。

• 排查步骤：
  1. 使用Unity Memory Profiler：Memory Profiler可以抓取托管堆的快照，并展示对象之间的引用关系。重点查看ILTypeInstance和CrossBindingAdaptor对象的引用链，看是谁在持有它们，阻止GC回收。
  2. 检查静态引用：这是热更域内存泄漏的重灾区。仔细审查热更代码中的所有静态字段、静态容器（如static List<...>），确保在模块卸载或适当时机被清空。
  3. 检查事件与委托：如前所述，未取消订阅的事件是导致跨域循环引用的元凶。确保成对出现（AddListener/RemoveListener,+=/-=）。
  4. 模拟卸载：在编辑器中，手动触发热更模块的卸载和重新加载，观察Profiler中的对象数量是否先下降再上升。如果只升不降，则肯定存在泄漏。

7.4 调试器连接失败或无法命中断点

• 检查清单：
  1. 端口与防火墙：确认调试端口（默认56000）是否被占用，防火墙是否阻止了连接。
  2. PDB文件：确认加载DLL时同时加载了PDB文件，且PDB与DLL版本完全匹配（编译时间一致）。
  3. 源码路径：PDB中记录的源码路径是否与IDE中打开的项目路径一致？如果不一致，需要在IDE的调试设置中添加符号文件路径映射。
  4. 调试器类型：确保在附加到Unity进程时，选择了正确的调试器类型（“使用Unity调试器连接”或“托管（CoreCLR）”）。
  5. ILRuntime初始化顺序：确保在启动调试服务（StartDebugService）之前，已经完成了所有必要的类型注册和适配器注册，否则断点可能无法正确绑定。

7.5 热更后功能异常，但无报错

这种情况最棘手，通常是逻辑错误或状态不一致。

• 排查：
  1. 版本混淆：确认客户端加载的确实是你刚刚部署的新DLL，而不是缓存的旧版本。检查版本号日志。
  2. 数据兼容性：热更代码修改了某个类的数据结构（如增加/删除字段），但本地持久化数据（如PlayerPrefs或本地文件）还是旧格式。反序列化时可能静默失败或产生默认值。需要在热更初始化时加入数据迁移逻辑。
  3. 流程依赖：新的热更逻辑可能依赖于某个必须在主工程特定时机初始化的数据或服务，但这个时机在新旧版本间发生了变化。仔细检查热更模块Initialize的调用时机和依赖条件。
  4. 增加日志：在怀疑出问题的逻辑分支前后，添加详细的日志输出，对比新旧版本的行为差异。ILRuntime的日志需要通过appDomain.DebugService输出到Unity才方便查看。

热更新是一个系统工程，它考验的不仅是编码能力，更是架构设计、工程化和运维的综合能力。ILRuntime 3.0提供了强大的基础能力，但将其威力发挥到极致，离不开这些围绕性能、架构、工作流和稳定性的核心技巧。从清晰的通信边界设计开始，到性能极致的编码习惯，再到流畅的开发调试体验、模块化的架构，最后辅以自动化的发布流程和严谨的测试，这套组合拳打下来，才能让你在面对热更新这个“难题”时，真正做到游刃有余，一网打尽。