C#热更原理为何原生不支持DLL替换做服务端或者Unity客户端的朋友大概率都听过“热更”这个说法。我最早被拉到这类问题面前是好几年前上线一个C#写的后台服务当时同事信誓旦旦地说“改个逻辑直接把新编译的DLL丢上去就行”。结果一操作Windows直接报“文件被占用”进程里老代码继续跑改了个寂寞。后来真把这套东西的底层机制翻了个底朝天才明白一句话C#不是不能热更而是CLR在设计上就没打算让你用“替换DLL”这种朴素方式去热更。这篇文章我尽量把这事的来龙去脉讲透CLR到底怎么加载程序集、为什么直接换DLL会失败、业界目前主流的热更方案底层逻辑是什么以及真到了要自己落地热更时哪些坑是绕不过去的。如果你正在纠结“我的C#项目要不要上热更”“为什么网上都说原生不支持”这篇内容可以当作一份参考索引。1. 先从一次失败的“热更”说起替换DLL到底卡在哪1.1 “文件被占用”只是第一层表象很多人第一次尝试热更都是从“替换DLL文件”开始的。在Windows上你大概率会撞见这个对话框进程正在运行DLL被当成可执行映像映射进了进程地址空间文件系统层面就被加了共享锁。你要么先停进程再替换要么等进程结束。这一步就堵死了“不停机、直接换文件”的幻想。但如果说“把文件锁放开就能热更”那就太小看CLR了。就算你用各种手段绕过文件锁比如先把新DLL复制成另一个文件名再想办法让进程加载真正致命的问题还在后面。1.2 即使文件换成功了类型也不认账CLR在进程内维护一套程序集加载上下文。同一个进程里**程序集标识Assembly Name 版本 公钥令牌 文化**唯一决定一个已加载的程序集。你第一次Load进来的叫MyGame.Logic, Version1.0.0.0那整个进程生命周期里凡是引用这个标识的所有代码拿到的都是第一次加载的那份元数据和IL。你把硬盘上的DLL换成Version1.0.0.0的新文件CLR不关心文件内容是否变化——只要程序集标识没变它就觉得“这个我已经加载过了”于是直接返回旧的程序集对象。那如果我把新DLL的版本号改成2.0呢文件锁确实没有但程序集版本升级不是改个数字那么简单强名称签名、依赖引用解析、配置文件里的绑定重定向还得看旧类型和新类型之间的状态迁移。更麻烦的是已经被编译器“钉死”的类型引用在JIT编译后的原生代码里已经写死了字段偏移和方法表地址——你旧逻辑里new出来的对象字段布局跟新类型对不上就算强行替换后续访问对象的字段和虚方法鬼知道会读到什么。1.3 热更的本质不是“文件替换”是“类型状态迁移”把上面两条结论放一起就能理解一个核心判断C#程序集的加载是进程生命周期的静态快照CLR假设“程序集一旦加载定义的类型、方法表、字段布局、静态变量位置就全部固定”。热更在C#语境下真正要做的事不是替换文件而是在不重启进程的前提下把旧类型从运行中的世界里摘下来再让新类型无缝接替旧类型的职责。这件事的难点不在“怎么编译新代码”而在“旧状态怎么办”。举个例子你有一个在线玩家列表Player类上挂了血量、坐标、背包数据这些对象全活着呢。你换了新Player类旧的Player实例怎么转换成新Player实例字段语义变了怎么办接口实现变了怎么办事件订阅关系断了怎么办这些事情CLR一概不负责——所以原生不支持“热血替换”本质上是CLR把这个烫手山芋直接扔给了开发者。2. CLR的程序集加载机制为什么连“卸载”都这么难2.1 程序集加载上下文与标识绑定要理解C#热更的死穴得先理解CLR的加载模型。.NET Framework时代加载程序集的入口主要是三个Assembly.Load(AssemblyName)走默认加载上下文以程序集名称为键进程内只加载一份。Assembly.LoadFrom(path)按路径加载会进LoadFrom上下文跟默认上下文有一堆复杂的依赖解析规则交互。Assembly.Load(byte[])直接从字节数组加载不落地文件但无法被卸载.NET Framework时代这是大坑。我看到很多人一开始觉得“从字节数组Load不就绕开文件锁了吗”——没错文件锁绕开了但绕不开的是CLR的标识同一性原则。Assembly.Load出来的程序集如果内部标记了AssemblyName下次再用同名加载还是会跑到已加载的那份上。到了.NET Core / .NET 5CLR引入了AssemblyLoadContextALC这才算给热更开了半扇窗。ALC允许你创建自定义加载上下文加载同一个名称的程序集到不同ALC彼此算作不同程序集实例。配合CollectibleAssemblyLoadContext理论上可以卸载整个上下文——调用Unload()后只要没有外部引用残留CLR就会释放这个上下文里加载的所有程序集。2.2 方法表与JIT后的代码已经“钉死”在内存里光能加载还不能热更还得能“无缝切换”。这里就涉及CLR内部的核心数据结构——方法表MethodTable。C#代码在第一次被调用时JIT会把IL编译成原生汇编代码然后把方法的入口地址回填到方法表里。之后所有调用包括虚调用都直接跳到这个地址。假如你在运行时替换了DLL老方法表和新方法表是完全不同的地址——但程序里已经编译好的调用点存的还是老地址。更糟的是类型布局。CLR在加载类型时会计算每个字段的偏移量对象分配就是按这个布局开内存。热更之后新类型字段变了那老对象的内存布局跟新类型的预期就不一致轻则字段读错重则内存越界直接崩溃。这就是为什么“替换”在CLR面前等于是“把一块已经盖好的楼的地基给换了但楼上还住着人”。2.3 静态变量热更最隐蔽的陷阱就算你绕开了上面所有障碍还有一个杀手级问题静态变量。C#的静态变量和static readonly字段存储位置是在进程的**高频率堆High-Frequency Heap**里跟程序集类型是一一绑定的。旧的ConfigManager.Instance可能被一大堆对象引用你换了新程序集新类型也有自己的静态变量位但老对象里拿到的ConfigManager引用还指向旧地址新旧静态数据完全焊死互相不认。业务上常见的“改了配置没生效”“状态不同步”这类诡异Bug根源很多时候就在这。从这些机制可以看到CLR为了极致的类型安全和性能把“代码约定的稳定不变”当成了基础设施级的假设。热更这种“运行时让代码自我迭代”的需求跟这个假设天然打架。3. 没有“DLL替换”那C#项目究竟怎么热更3.1 方案一把“逻辑”搬到非C#的脚本层最常见这是游戏行业用得最广的一套思路C#只做引擎和底层框架具体游戏逻辑全部用Lua或别的脚本写上线修逻辑只改脚本文件重启都不用。C#进程里跑了一个Lua虚拟机配置、玩法、数值全在脚本层。因为脚本层永远不参与C#程序集的编译替换脚本天然不受CLR加载机制约束。代表性方案就是XLua / tolua。我以前在一个中大型Unity项目里用过这套实测下来线上并发和内存开销都还能接受。缺点也明显Lua写得多了类型安全、热更效率、IDE没智能提示到大后期维护成本吓人。而且要维护“C#层能力暴露给Lua”的绑定代码每加一个接口就得同步导出漏一个就是线上事故。3.2 方案二解释执行C# ILILRuntime思路如果你不想全上Lua只想“还在C#里写逻辑”那ILRuntime这类方案走了另一条路把热更代码编译成普通C#程序集DLL但运行时不是交给CLR JIT执行而是用IL解释器逐条执行IL指令。ILRuntime自己实现了一套解释栈每条IL指令ldarg、callvirt、newobj这种对应解释器里的一个处理分支。这种方案的好处是开发语言和业务逻辑全在C#生态内改完重新编译DLL替换文件只要解释器还在跑新逻辑就能被解释器读到。坏处也实在性能折损非常明显复杂计算场景会比原生JIT慢很多而且遇到泛型、委托、值类型这些IL重操作解释器需要做大量“补偿工作”代码写得太溜反而容易踩到解释器限制的暗礁。3.3 方案三代码生成 程序集隔离正经的运行时热更真正能算“热更”而不是“脚本化”的做法是运行时隔离 量大管饱的代码生成。思路是这样启动进程后业务代码跑在可卸载的独立AssemblyLoadContext里。热更时用Roslyn动态编译新代码内存里生成新DLL创建新的ALC加载。旧ALC的实例通过一套“状态迁移接口”手动把业务关键状态玩家数据、配置、缓存序列化/复制到新对象上。旧的ALC执行Unload()等所有旧引用被GC清掉OS层文件锁自然释放。这套方案Unity侧用得少Unity的IL2CPP环境下没有完整的ALC语义反而是自研服务器、客户端工具链、插件系统里很常见。难点在于你得为“每个热更新的实体类型”精心设计跨代际的状态迁移逻辑。忘迁移一个字段线上数据就丢了状态迁移顺序反了对象构造器跑出来一堆空引用。比起写业务写这套“搬家系统”本身更像在做一个迷你版的ORM。3.4 方案四HybridCLR原huatuo为代表的“真·代码热更”如果你在Unity圈子这两年被讨论最多的热更技术基本绕不开HybridCLR。它的核心思路是让CLR动态加载新DLL然后用“解释模式”执行那些没有被AOT编译的原生代码。IL2CPP环境下Unity把C#代码AOT编译成C再编进原生库本来没有JIT能力HybridCLR给这套AOT世界塞了一个解释器——AOT编译过的调用约定遇到“这个类或方法没有原生实现”就转到解释器去跑。这套方案最直观的好处是用法沿袭C#原生不用换语言也不用手把手迁移状态。它本质上是“方案二”的工程化逆袭ILRuntime是自建解释器、接入代价高HybridCLR尽量做到“DLL换一换、元数据补一补、解释器自动兜底”。代价呢底层非常深、版本敏感、联调调试麻烦。IL2CPP每次升级HybridCLR的底层hook也得跟着进化。你一旦接进去就等于跟这个框架深度绑定住了遇到问题指望搜索引擎不如直接去看它的源码和issue区。4. 实战对照不同技术栈下热更的落地与取舍4.1 表格对比四种主流途径的定位差异方案逻辑载体热更体验性能影响实现/接入难度适用领域Lua脚本XLua/toluaLua层改文件即生效中高委托跨语言转发、GC压力中绑定导出繁琐Unity商业游戏、策划驱动玩法ILRuntime编译为DLL的C#替换DLL重启解释器高解释执行较慢中控制边界要自己设计偏中小型Unity项目、逻辑中重度ALC自定义加载器C#程序集需写状态迁移低CLR原生JIT高迁移逻辑复杂服务端插件、桌面工具、自研框架HybridCLRC#程序集替换DLL生成桥接中等解释器兜底高引擎适配、版本敏感Unity项目追求纯C#热更这是我个人在项目里用过一遍之后的主观评估。注意“性能影响”那一栏在不同项目里差距很大如果是IO密集、UI事件密集而CPU计算不重的场景解释执行那套通常足够用如果每一帧都在做海量数值运算那原生JIT或AOT带来的差距就藏不住了。4.2 状态迁移是任何方案绕不过去的核心工作量不管选哪条路一个核心事实始终存在热更不只是换代码迁移状态才是主体工作量。我曾经在一个热更模块重构时光是把“在线房间状态机”迁移正确就花了三天。对象树里嵌套了房间、玩家、队列、定时器、事件订阅每一层都要处理。我的建议是在系统设计阶段就给“热更状态”划定边界热更模块内尽量用数据驱动而非对象直接引用。RPC、事件、消息都走ID或键值减少新旧类型之间的直接握手。热更边界做显式接口。一个实体要是想被热更必须实现IStateTransferable这类接口自己负责导出状态和导入状态。没实现的类热更工具连碰都不碰。设计一个补丁版本号。每次热更包携带一个递增版本号客户端加载时缓存旧状态、加载新逻辑、按版本号做增量迁移。版本从1到2跟从1到99迁移逻辑完全不同——你得能同时处理“只差一步”和“差一整年”的情况。4.3 实测一次ALC热更的完整链路附关键代码下面这段是我自己实现过的“简易ALC热更加载器”核心流程适合服务端工具链场景Unity侧参考思路即可不能直接照搬。public class HotPatchLoader : IDisposable { private CollectibleAssemblyLoadContext _alc; public Assembly LoadPatch(string dllPath, string pdbPath) { // 1. 每次热更都新建独立 ALC避免污染主上下文 _alc new CollectibleAssemblyLoadContext(); // 2. 读取字节而非直接 loadfrom // 避免程序集被文件系统锁住导致后续更新失败 byte[] dllBytes File.ReadAllBytes(dllPath); byte[] pdbBytes File.Exists(pdbPath) ? File.ReadAllBytes(pdbPath) : null; return _alc.LoadFromStream(new MemoryStream(dllBytes), pdbBytes null ? null : new MemoryStream(pdbBytes)); } public void UnloadContext() { // 3. 卸载上下文等待GC回收 _alc.Unload(); _alc null; GC.Collect(); GC.WaitForPendingFinalizers(); } public void Dispose() UnloadContext(); }这段代码看着简单实际踩坑点多了去了依赖解析新程序集引用了主上下文里的框架DLL或者引用了旧ALC里的其他程序集必须在Resolving事件里写好解析逻辑不然运行时到处找DLL找不到。跨上下文类型不是同一类型就算两个ALC加载了同名的Player类它们依然是两个完全不同的System.Type。方法参数用object传对象反射调方法完全走动态绑定。Unload不代表立刻释放Unload()只是标记删除真正释放要等所有实例被GC。静态委托、事件订阅、ThreadLocal、finalizer里各种隐藏引用都是导致“卸载失败”的头号元凶。排查时用WeakReference盯着ALC对象调用Unload()后主动GC.Collect()几次看到IsAlive false才算真卸干净。5. 那些年踩过的坑从文件锁到诡异的“改了多少次都没变”5.1 看起来热更成功但行为还是老代码这是最让新人崩溃的场景DLL替换成功了进程也起了新版本结果跑起来还是老逻辑。原因多半在程序集标识没有变化而加载代码走的是Assembly.Load(MyLogic, Version1.0.0.0)这种按名称加载的路径。CLR发现进程里已经有同名程序集直接返回旧引用硬盘上的新文件根本没被加载。正确做法是每次热更都“释放旧引用、走独立上下文重新加载”。如果你没有ALC环境比如Unity Mono时代那就只能用“每次加载从byte[]读取并且保证程序集版本号变化”这个土办法。版本号不升再努力也没用。5.2 字段偏移陷阱一道“加字段”引发的血案有个经典事故线上运行中的旧版本Player类有五个字段热更新版本给类加了一个int Level。因为程序设计时没有走状态迁移只是“换个DLL”结果新代码读Level字段时CLR按新的字段偏移去旧对象内存里取数据。老对象里偏移位置存的是另一个字段的数据线上所有玩家等级直接乱掉。这种事不是个例是静态类型语言热更最容易被忽略、后果最严重的问题。所以我在任何团队里都会反复强调运行时热更优先用“追加新类”而不是“修改旧类”。旧类原封不动留着新逻辑通过新类包装、转调老实例完全不碰。要改字段就新建一个PlayerV2让旧的Player里的关键数据“搬家”过去。虽然绕一点但能把“字段对齐”这个地雷直接拆掉。5.3 热更包怎么解决“改脚本才生效”的焦虑搞Lua热更的时候有个常见的认知偏差以为“脚本更新 所有逻辑能马上换”。实际上Lua层一层套一层一个require缓存了旧表策划改了数值脚本游戏还是要重启才能拿到新数值或者要手动清理package.loaded里的旧模块。成熟的方案是给每个热更模块做模块级版本号加载记录在玩家数据里做“按需重载”战斗模块版本号变了就重载战斗相关脚本UI模块变了就重载UI。宁可多写几个重载入口也别图省事一把梭清掉所有package.loaded。5.4 热更安全你和生产环境之间还差一个“验证通道”最后说一个被低估的工程问题怎么杀回滚。无论本地测得多好热更包发布后总有可能线上翻车。C#原生没给你“一键回退到上一个DLL”的能力所以你要在打热更包时就留好“向前兼容”的兜底旧版本入口代码不能删旧配置序列化格式不能破数据表加列必须给默认值。我把这叫作“热更的不可逆条约”。经验是每次都想办法让热更包可以同时被两个版本理解。往配置表加一组字段旧代码不能因此崩往消息协议加一个字段旧逻辑不能因此错。做不到“兼容两个版本”的热更就像闭着眼走钢丝迟早摔跟头。6. 聊聊两条“热更真相”为什么没人愿意明文告诉你6.1 所谓“原生不支持”其实是个设计取舍CLR不原生支持DLL热替换不是“技术还没做到”而是权衡之后决定不做。C#的卖点就是强类型、高性能、代码安全这就要求JIT编译出的代码可以大胆做各种优化——内联、字段偏移固化、方法表稳定。一旦“程序集会随时被换掉”这些优化就全得打折扣。为了给少数热更场景开洞动摇核心设计的地基对一门通用语言来说不划算。跟Java对比一下JVM同样不允许“简单替换class文件立即全量生效”哪怕很多Java服务器“热部署”做得热火朝天那也是靠ClassLoader隔离新加载的类。Cyclic依赖、老实例状态、静态变量问题照样存在只不过Java框架层比如OSGi、Spring Boot DevTools封装了一堆迁移逻辑让你看起来“好像行”。本质思路跟C#的ALC是同一回事。6.2 热更方案的稳定性比拼的是“边界设计”而不是“底层技术”聊到最后我发现真正决定一个项目热更能不能长久跑下去的不是选了哪套底层方案而是有没有认认真真划好“热更边界”。什么是热更边界哪些类可以热更哪些类是框架层永不热更热更模块之间只能通过接口和消息通信任何跨热更新的状态流转必须有序列化方案热更包文件必须带强校验和清晰版本。这几条做得好了哪怕你在用最土的Assembly.Load(byte[]) 版本号递增方案也能稳定跑很久。这几条做不好就算上了HybridCLR、ALC全家桶一样会被类卸载不了、状态对不齐、版本回滚混乱这类问题拖进泥潭。我在实际入手热更前最推荐的做法是先别急着选技术方案。先把你的业务拆成三块——永远不会变的核心、经常要调的逻辑、跟数据强相关的实体。然后把“经常要调”的那部分做成脚本化或程序集隔离剩下两块专注稳定性。热更不只是个技术动作它本质上是一项代码架构工程。最后再分享一点很现实的心得C#热更没有银弹凡是有人告诉你“用某个库加上一个方法就能热更”的九个最后都要面对状态迁移和边界设计的苦战。但只要你理解了CLR的加载模型、程序集标识、静态变量和类型布局这些底层机制就会发现所有方案背后的逻辑都能串起来——被人为包装过的“热更黑科技”感也会迅速消退成“不过是把CLR的脾性摸清了而已”。 
长河君 · 2026/10/9 9:22:54 · 阅读 1.2k C#热更新原理：CLR为何不允许直接替换DLL？
C#热更原理为何原生不支持DLL替换做服务端或者Unity客户端的朋友大概率都听过“热更”这个说法。我最早被拉到这类问题面前是好几年前上线一个C#写的后台服务当时同事信誓旦旦地说“改个逻辑直接把新编译的DLL丢上去就行”。结果一操作Windows直接报“文件被占用”进程里老代码继续跑改了个寂寞。后来真把这套东西的底层机制翻了个底朝天才明白一句话C#不是不能热更而是CLR在设计上就没打算让你用“替换DLL”这种朴素方式去热更。这篇文章我尽量把这事的来龙去脉讲透CLR到底怎么加载程序集、为什么直接换DLL会失败、业界目前主流的热更方案底层逻辑是什么以及真到了要自己落地热更时哪些坑是绕不过去的。如果你正在纠结“我的C#项目要不要上热更”“为什么网上都说原生不支持”这篇内容可以当作一份参考索引。1. 先从一次失败的“热更”说起替换DLL到底卡在哪1.1 “文件被占用”只是第一层表象很多人第一次尝试热更都是从“替换DLL文件”开始的。在Windows上你大概率会撞见这个对话框进程正在运行DLL被当成可执行映像映射进了进程地址空间文件系统层面就被加了共享锁。你要么先停进程再替换要么等进程结束。这一步就堵死了“不停机、直接换文件”的幻想。但如果说“把文件锁放开就能热更”那就太小看CLR了。就算你用各种手段绕过文件锁比如先把新DLL复制成另一个文件名再想办法让进程加载真正致命的问题还在后面。1.2 即使文件换成功了类型也不认账CLR在进程内维护一套程序集加载上下文。同一个进程里**程序集标识Assembly Name 版本 公钥令牌 文化**唯一决定一个已加载的程序集。你第一次Load进来的叫MyGame.Logic, Version1.0.0.0那整个进程生命周期里凡是引用这个标识的所有代码拿到的都是第一次加载的那份元数据和IL。你把硬盘上的DLL换成Version1.0.0.0的新文件CLR不关心文件内容是否变化——只要程序集标识没变它就觉得“这个我已经加载过了”于是直接返回旧的程序集对象。那如果我把新DLL的版本号改成2.0呢文件锁确实没有但程序集版本升级不是改个数字那么简单强名称签名、依赖引用解析、配置文件里的绑定重定向还得看旧类型和新类型之间的状态迁移。更麻烦的是已经被编译器“钉死”的类型引用在JIT编译后的原生代码里已经写死了字段偏移和方法表地址——你旧逻辑里new出来的对象字段布局跟新类型对不上就算强行替换后续访问对象的字段和虚方法鬼知道会读到什么。1.3 热更的本质不是“文件替换”是“类型状态迁移”把上面两条结论放一起就能理解一个核心判断C#程序集的加载是进程生命周期的静态快照CLR假设“程序集一旦加载定义的类型、方法表、字段布局、静态变量位置就全部固定”。热更在C#语境下真正要做的事不是替换文件而是在不重启进程的前提下把旧类型从运行中的世界里摘下来再让新类型无缝接替旧类型的职责。这件事的难点不在“怎么编译新代码”而在“旧状态怎么办”。举个例子你有一个在线玩家列表Player类上挂了血量、坐标、背包数据这些对象全活着呢。你换了新Player类旧的Player实例怎么转换成新Player实例字段语义变了怎么办接口实现变了怎么办事件订阅关系断了怎么办这些事情CLR一概不负责——所以原生不支持“热血替换”本质上是CLR把这个烫手山芋直接扔给了开发者。2. CLR的程序集加载机制为什么连“卸载”都这么难2.1 程序集加载上下文与标识绑定要理解C#热更的死穴得先理解CLR的加载模型。.NET Framework时代加载程序集的入口主要是三个Assembly.Load(AssemblyName)走默认加载上下文以程序集名称为键进程内只加载一份。Assembly.LoadFrom(path)按路径加载会进LoadFrom上下文跟默认上下文有一堆复杂的依赖解析规则交互。Assembly.Load(byte[])直接从字节数组加载不落地文件但无法被卸载.NET Framework时代这是大坑。我看到很多人一开始觉得“从字节数组Load不就绕开文件锁了吗”——没错文件锁绕开了但绕不开的是CLR的标识同一性原则。Assembly.Load出来的程序集如果内部标记了AssemblyName下次再用同名加载还是会跑到已加载的那份上。到了.NET Core / .NET 5CLR引入了AssemblyLoadContextALC这才算给热更开了半扇窗。ALC允许你创建自定义加载上下文加载同一个名称的程序集到不同ALC彼此算作不同程序集实例。配合CollectibleAssemblyLoadContext理论上可以卸载整个上下文——调用Unload()后只要没有外部引用残留CLR就会释放这个上下文里加载的所有程序集。2.2 方法表与JIT后的代码已经“钉死”在内存里光能加载还不能热更还得能“无缝切换”。这里就涉及CLR内部的核心数据结构——方法表MethodTable。C#代码在第一次被调用时JIT会把IL编译成原生汇编代码然后把方法的入口地址回填到方法表里。之后所有调用包括虚调用都直接跳到这个地址。假如你在运行时替换了DLL老方法表和新方法表是完全不同的地址——但程序里已经编译好的调用点存的还是老地址。更糟的是类型布局。CLR在加载类型时会计算每个字段的偏移量对象分配就是按这个布局开内存。热更之后新类型字段变了那老对象的内存布局跟新类型的预期就不一致轻则字段读错重则内存越界直接崩溃。这就是为什么“替换”在CLR面前等于是“把一块已经盖好的楼的地基给换了但楼上还住着人”。2.3 静态变量热更最隐蔽的陷阱就算你绕开了上面所有障碍还有一个杀手级问题静态变量。C#的静态变量和static readonly字段存储位置是在进程的**高频率堆High-Frequency Heap**里跟程序集类型是一一绑定的。旧的ConfigManager.Instance可能被一大堆对象引用你换了新程序集新类型也有自己的静态变量位但老对象里拿到的ConfigManager引用还指向旧地址新旧静态数据完全焊死互相不认。业务上常见的“改了配置没生效”“状态不同步”这类诡异Bug根源很多时候就在这。从这些机制可以看到CLR为了极致的类型安全和性能把“代码约定的稳定不变”当成了基础设施级的假设。热更这种“运行时让代码自我迭代”的需求跟这个假设天然打架。3. 没有“DLL替换”那C#项目究竟怎么热更3.1 方案一把“逻辑”搬到非C#的脚本层最常见这是游戏行业用得最广的一套思路C#只做引擎和底层框架具体游戏逻辑全部用Lua或别的脚本写上线修逻辑只改脚本文件重启都不用。C#进程里跑了一个Lua虚拟机配置、玩法、数值全在脚本层。因为脚本层永远不参与C#程序集的编译替换脚本天然不受CLR加载机制约束。代表性方案就是XLua / tolua。我以前在一个中大型Unity项目里用过这套实测下来线上并发和内存开销都还能接受。缺点也明显Lua写得多了类型安全、热更效率、IDE没智能提示到大后期维护成本吓人。而且要维护“C#层能力暴露给Lua”的绑定代码每加一个接口就得同步导出漏一个就是线上事故。3.2 方案二解释执行C# ILILRuntime思路如果你不想全上Lua只想“还在C#里写逻辑”那ILRuntime这类方案走了另一条路把热更代码编译成普通C#程序集DLL但运行时不是交给CLR JIT执行而是用IL解释器逐条执行IL指令。ILRuntime自己实现了一套解释栈每条IL指令ldarg、callvirt、newobj这种对应解释器里的一个处理分支。这种方案的好处是开发语言和业务逻辑全在C#生态内改完重新编译DLL替换文件只要解释器还在跑新逻辑就能被解释器读到。坏处也实在性能折损非常明显复杂计算场景会比原生JIT慢很多而且遇到泛型、委托、值类型这些IL重操作解释器需要做大量“补偿工作”代码写得太溜反而容易踩到解释器限制的暗礁。3.3 方案三代码生成 程序集隔离正经的运行时热更真正能算“热更”而不是“脚本化”的做法是运行时隔离 量大管饱的代码生成。思路是这样启动进程后业务代码跑在可卸载的独立AssemblyLoadContext里。热更时用Roslyn动态编译新代码内存里生成新DLL创建新的ALC加载。旧ALC的实例通过一套“状态迁移接口”手动把业务关键状态玩家数据、配置、缓存序列化/复制到新对象上。旧的ALC执行Unload()等所有旧引用被GC清掉OS层文件锁自然释放。这套方案Unity侧用得少Unity的IL2CPP环境下没有完整的ALC语义反而是自研服务器、客户端工具链、插件系统里很常见。难点在于你得为“每个热更新的实体类型”精心设计跨代际的状态迁移逻辑。忘迁移一个字段线上数据就丢了状态迁移顺序反了对象构造器跑出来一堆空引用。比起写业务写这套“搬家系统”本身更像在做一个迷你版的ORM。3.4 方案四HybridCLR原huatuo为代表的“真·代码热更”如果你在Unity圈子这两年被讨论最多的热更技术基本绕不开HybridCLR。它的核心思路是让CLR动态加载新DLL然后用“解释模式”执行那些没有被AOT编译的原生代码。IL2CPP环境下Unity把C#代码AOT编译成C再编进原生库本来没有JIT能力HybridCLR给这套AOT世界塞了一个解释器——AOT编译过的调用约定遇到“这个类或方法没有原生实现”就转到解释器去跑。这套方案最直观的好处是用法沿袭C#原生不用换语言也不用手把手迁移状态。它本质上是“方案二”的工程化逆袭ILRuntime是自建解释器、接入代价高HybridCLR尽量做到“DLL换一换、元数据补一补、解释器自动兜底”。代价呢底层非常深、版本敏感、联调调试麻烦。IL2CPP每次升级HybridCLR的底层hook也得跟着进化。你一旦接进去就等于跟这个框架深度绑定住了遇到问题指望搜索引擎不如直接去看它的源码和issue区。4. 实战对照不同技术栈下热更的落地与取舍4.1 表格对比四种主流途径的定位差异方案逻辑载体热更体验性能影响实现/接入难度适用领域Lua脚本XLua/toluaLua层改文件即生效中高委托跨语言转发、GC压力中绑定导出繁琐Unity商业游戏、策划驱动玩法ILRuntime编译为DLL的C#替换DLL重启解释器高解释执行较慢中控制边界要自己设计偏中小型Unity项目、逻辑中重度ALC自定义加载器C#程序集需写状态迁移低CLR原生JIT高迁移逻辑复杂服务端插件、桌面工具、自研框架HybridCLRC#程序集替换DLL生成桥接中等解释器兜底高引擎适配、版本敏感Unity项目追求纯C#热更这是我个人在项目里用过一遍之后的主观评估。注意“性能影响”那一栏在不同项目里差距很大如果是IO密集、UI事件密集而CPU计算不重的场景解释执行那套通常足够用如果每一帧都在做海量数值运算那原生JIT或AOT带来的差距就藏不住了。4.2 状态迁移是任何方案绕不过去的核心工作量不管选哪条路一个核心事实始终存在热更不只是换代码迁移状态才是主体工作量。我曾经在一个热更模块重构时光是把“在线房间状态机”迁移正确就花了三天。对象树里嵌套了房间、玩家、队列、定时器、事件订阅每一层都要处理。我的建议是在系统设计阶段就给“热更状态”划定边界热更模块内尽量用数据驱动而非对象直接引用。RPC、事件、消息都走ID或键值减少新旧类型之间的直接握手。热更边界做显式接口。一个实体要是想被热更必须实现IStateTransferable这类接口自己负责导出状态和导入状态。没实现的类热更工具连碰都不碰。设计一个补丁版本号。每次热更包携带一个递增版本号客户端加载时缓存旧状态、加载新逻辑、按版本号做增量迁移。版本从1到2跟从1到99迁移逻辑完全不同——你得能同时处理“只差一步”和“差一整年”的情况。4.3 实测一次ALC热更的完整链路附关键代码下面这段是我自己实现过的“简易ALC热更加载器”核心流程适合服务端工具链场景Unity侧参考思路即可不能直接照搬。public class HotPatchLoader : IDisposable { private CollectibleAssemblyLoadContext _alc; public Assembly LoadPatch(string dllPath, string pdbPath) { // 1. 每次热更都新建独立 ALC避免污染主上下文 _alc new CollectibleAssemblyLoadContext(); // 2. 读取字节而非直接 loadfrom // 避免程序集被文件系统锁住导致后续更新失败 byte[] dllBytes File.ReadAllBytes(dllPath); byte[] pdbBytes File.Exists(pdbPath) ? File.ReadAllBytes(pdbPath) : null; return _alc.LoadFromStream(new MemoryStream(dllBytes), pdbBytes null ? null : new MemoryStream(pdbBytes)); } public void UnloadContext() { // 3. 卸载上下文等待GC回收 _alc.Unload(); _alc null; GC.Collect(); GC.WaitForPendingFinalizers(); } public void Dispose() UnloadContext(); }这段代码看着简单实际踩坑点多了去了依赖解析新程序集引用了主上下文里的框架DLL或者引用了旧ALC里的其他程序集必须在Resolving事件里写好解析逻辑不然运行时到处找DLL找不到。跨上下文类型不是同一类型就算两个ALC加载了同名的Player类它们依然是两个完全不同的System.Type。方法参数用object传对象反射调方法完全走动态绑定。Unload不代表立刻释放Unload()只是标记删除真正释放要等所有实例被GC。静态委托、事件订阅、ThreadLocal、finalizer里各种隐藏引用都是导致“卸载失败”的头号元凶。排查时用WeakReference盯着ALC对象调用Unload()后主动GC.Collect()几次看到IsAlive false才算真卸干净。5. 那些年踩过的坑从文件锁到诡异的“改了多少次都没变”5.1 看起来热更成功但行为还是老代码这是最让新人崩溃的场景DLL替换成功了进程也起了新版本结果跑起来还是老逻辑。原因多半在程序集标识没有变化而加载代码走的是Assembly.Load(MyLogic, Version1.0.0.0)这种按名称加载的路径。CLR发现进程里已经有同名程序集直接返回旧引用硬盘上的新文件根本没被加载。正确做法是每次热更都“释放旧引用、走独立上下文重新加载”。如果你没有ALC环境比如Unity Mono时代那就只能用“每次加载从byte[]读取并且保证程序集版本号变化”这个土办法。版本号不升再努力也没用。5.2 字段偏移陷阱一道“加字段”引发的血案有个经典事故线上运行中的旧版本Player类有五个字段热更新版本给类加了一个int Level。因为程序设计时没有走状态迁移只是“换个DLL”结果新代码读Level字段时CLR按新的字段偏移去旧对象内存里取数据。老对象里偏移位置存的是另一个字段的数据线上所有玩家等级直接乱掉。这种事不是个例是静态类型语言热更最容易被忽略、后果最严重的问题。所以我在任何团队里都会反复强调运行时热更优先用“追加新类”而不是“修改旧类”。旧类原封不动留着新逻辑通过新类包装、转调老实例完全不碰。要改字段就新建一个PlayerV2让旧的Player里的关键数据“搬家”过去。虽然绕一点但能把“字段对齐”这个地雷直接拆掉。5.3 热更包怎么解决“改脚本才生效”的焦虑搞Lua热更的时候有个常见的认知偏差以为“脚本更新 所有逻辑能马上换”。实际上Lua层一层套一层一个require缓存了旧表策划改了数值脚本游戏还是要重启才能拿到新数值或者要手动清理package.loaded里的旧模块。成熟的方案是给每个热更模块做模块级版本号加载记录在玩家数据里做“按需重载”战斗模块版本号变了就重载战斗相关脚本UI模块变了就重载UI。宁可多写几个重载入口也别图省事一把梭清掉所有package.loaded。5.4 热更安全你和生产环境之间还差一个“验证通道”最后说一个被低估的工程问题怎么杀回滚。无论本地测得多好热更包发布后总有可能线上翻车。C#原生没给你“一键回退到上一个DLL”的能力所以你要在打热更包时就留好“向前兼容”的兜底旧版本入口代码不能删旧配置序列化格式不能破数据表加列必须给默认值。我把这叫作“热更的不可逆条约”。经验是每次都想办法让热更包可以同时被两个版本理解。往配置表加一组字段旧代码不能因此崩往消息协议加一个字段旧逻辑不能因此错。做不到“兼容两个版本”的热更就像闭着眼走钢丝迟早摔跟头。6. 聊聊两条“热更真相”为什么没人愿意明文告诉你6.1 所谓“原生不支持”其实是个设计取舍CLR不原生支持DLL热替换不是“技术还没做到”而是权衡之后决定不做。C#的卖点就是强类型、高性能、代码安全这就要求JIT编译出的代码可以大胆做各种优化——内联、字段偏移固化、方法表稳定。一旦“程序集会随时被换掉”这些优化就全得打折扣。为了给少数热更场景开洞动摇核心设计的地基对一门通用语言来说不划算。跟Java对比一下JVM同样不允许“简单替换class文件立即全量生效”哪怕很多Java服务器“热部署”做得热火朝天那也是靠ClassLoader隔离新加载的类。Cyclic依赖、老实例状态、静态变量问题照样存在只不过Java框架层比如OSGi、Spring Boot DevTools封装了一堆迁移逻辑让你看起来“好像行”。本质思路跟C#的ALC是同一回事。6.2 热更方案的稳定性比拼的是“边界设计”而不是“底层技术”聊到最后我发现真正决定一个项目热更能不能长久跑下去的不是选了哪套底层方案而是有没有认认真真划好“热更边界”。什么是热更边界哪些类可以热更哪些类是框架层永不热更热更模块之间只能通过接口和消息通信任何跨热更新的状态流转必须有序列化方案热更包文件必须带强校验和清晰版本。这几条做得好了哪怕你在用最土的Assembly.Load(byte[]) 版本号递增方案也能稳定跑很久。这几条做不好就算上了HybridCLR、ALC全家桶一样会被类卸载不了、状态对不齐、版本回滚混乱这类问题拖进泥潭。我在实际入手热更前最推荐的做法是先别急着选技术方案。先把你的业务拆成三块——永远不会变的核心、经常要调的逻辑、跟数据强相关的实体。然后把“经常要调”的那部分做成脚本化或程序集隔离剩下两块专注稳定性。热更不只是个技术动作它本质上是一项代码架构工程。最后再分享一点很现实的心得C#热更没有银弹凡是有人告诉你“用某个库加上一个方法就能热更”的九个最后都要面对状态迁移和边界设计的苦战。但只要你理解了CLR的加载模型、程序集标识、静态变量和类型布局这些底层机制就会发现所有方案背后的逻辑都能串起来——被人为包装过的“热更黑科技”感也会迅速消退成“不过是把CLR的脾性摸清了而已”。