搞了十多年 C 服务端和桌面端我一直觉得动态库热加载是被低估的一项技能。动态库谁都会用无非链接、调用、解绑定但一旦加上热加载三个字性质就变了——这意味着在进程不重启的前提下把正在运行的模块从内存里卸载、替换、再重新拉起来。这招在 AI 推理服务、游戏逻辑更新、7x24 小时后台任务里都是硬需求而且实际踩坑远比想象中多。这篇文章我会从 Windows DLL 的调用姿势讲起说清楚隐式链接和显式加载到底差在哪再深入热加载的核心机制最后用一个面向 onnxruntime 的动态库热加载实战来收尾——包括怎么用 VS 调 DLL、怎么让推理引擎的模型和库文件同时做到热更新、加载不上或卸载不干净时去哪排查。无论你是写桌面工具的还是维护线上服务的这波内容都能直接用。1. 动态库热加载到底解决什么问题1.1 三种加载时机对应三类需求很多人对动态库的理解停留在程序启动时自动加载其实从工程角度看动态库至少有三类完全不同的使用时机对应三种截然不同的业务需求。第一种是启动期加载也就是隐式链接。编译时通过导入库.lib和头文件绑定好exe 一启动系统加载器就会自动把依赖的 DLL 找齐、映射进进程地址空间。这种方式最简单绝大多数桌面软件都是这么做的缺点是启动时不行就是不行——少一个依赖 DLL程序直接弹窗报错没有任何补救机会。第二种是运行期按需加载也就是显式加载。通过LoadLibrary/GetProcAddressLinux 下是dlopen/dlsym在程序跑起来之后根据配置和业务逻辑临时决定要不要加载某个模块。比如一个采集软件只有在用户选择了海康相机才加载相机 SDK 的 DLL选了大华相机就加载另一家的。好处是灵活、资源不浪费坏处是调用链复杂函数指针和生命周期都要自己管理。第三种就是我们今天聊的热加载进程长期运行中把某个 DLL 完整卸载掉替换成新版本或新实现再把它重新加载进来。这跟前两种有本质区别——启动期加载和运行期按需加载都是一次加载终身使用而热加载要求模块具备可生可灭的能力。你想想一个服务跑了一个月内存里堆了几十万个对象如果某个业务模块的逻辑要升级传统做法是重启进程但如果这个服务承载着长连接、用户会话、模型状态重启的成本就可能是几十万用户同时掉线。热加载解决的就是这个问题让模块像 USB 一样随时插拔进程本身保持存活。用生活化的话说启动期加载像是你买房时把家电都装死在墙上按需加载像是租房子时缺啥买啥但买了就用到底热加载则是酒店客房服务——客人退房、打扫、下一个客人入住房间还是那个房间但里面的状态完全刷新。1.2 热加载与插件架构的关系热加载并不是一个孤立的技术点它天然会和插件架构绑定在一起。原因很简单不是每个 DLL 都能热加载的。如果一个 DLL 和主程序之间深度耦合、互相传递内部对象、共享全局状态那卸载时必然牵一发动全身。想做到安全热加载必须从设计阶段就把模块边界划清楚让模块通过稳定的接口层和主程序通信。典型的可热加载插件架构长这样主程序只依赖一个抽象的接口头文件比如IPlugin里面有Init、Execute、Release等纯虚函数插件 DLL 实现这个接口并且对外导出两个工厂函数——CreatePlugin和DestroyPlugin。主程序用LoadLibrary加载 DLL调用CreatePlugin拿到接口指针用完或要升级时先调用DestroyPlugin销毁对象再FreeLibrary卸载 DLL。所有跨模块传递的数据要么是基础类型要么是接口指针绝对不能把主程序内部的std::string、std::vector直接传给 DLL 去操作更不能让 DLL 分配的内存交给主程序去delete。这个架构聪明在哪它把能热加载从一种技巧变成了一种纪律。只要每个模块都恪守这个边界卸载就只是销毁对象 释放句柄 清引用计数的机械操作没有隐藏依赖、没有跨堆内存、没有全局状态纠缠。选择这种方案而不是直接在进程内改代码或升级时重启整个服务核心原因有三个一是可用性7x24 服务不允许中断热加载能把升级时间从分钟级压到毫秒级二是故障隔离插件崩溃不至于拖垮整个主程序坏模块可以独立降级三是灰度能力我可以只对部分连接加载新版本模块验证没问题再全量切。这三点在 AI 推理服务里尤其重要因为模型更新频率高而推理引擎本身也在持续迭代。2. 从 Windows DLL 讲起VS 里调用动态库的完整姿势2.1 隐式链接与显式加载的区别先别急着聊热加载得先把 Windows 下调用 DLL 的基础姿势理清楚。很多新手问如何用 VS 调用 DLL其实从机制上讲只有两条路隐式链接和显式加载。我见过太多人把这两者混在一起结果出了问题都不知道是加载阶段失败还是调用阶段失败。隐式链接依赖三个东西头文件、导入库.lib、DLL 文件。在 VS 工程里配置好附加包含目录附加库目录附加依赖项编译出来的 exe 在启动时就会自动加载 DLL。优点是调用起来跟普通函数一模一样编译器帮你搞定所有地址解析缺点是灵活性差依赖关系在编译期定死运行时 DLL 缺失或版本不对程序直接起不来更别提热更新了。显式加载则是运行时完全动态的。主程序只保存一个函数指针通过LoadLibrary拿模块句柄再通过GetProcAddress按名字取函数地址。整个过程不依赖任何 .lib 或头文件但最好还是用宏和 typedef 把函数签名固化下来程序的启动不会因为某个 DLL 不存在而失败——最多就是加载失败时给你返回一个NULL。这才是热加载的底层基础。我做个简单对比维度隐式链接显式加载加载时机进程启动时由系统加载器完成运行时按需调用 LoadLibrary依赖文件头文件 .lib .dll仅 .dll函数签名需要自己声明灵活性差依赖关系编译期固定好可加载、可卸载、可替换失败处理启动即失败无补救机会返回值可判断支持重试/降级热加载不支持支持是热加载的基础如果你只是做一个内部工具隐式链接省事没问题但如果你的 DLL 要做热更新或者要在运行时决定加载哪个后端实现那就必须显式加载。这个选择题没有中间态。2.2 用 VS 调用 DLL 的关键步骤下面走一遍用 VS 调用 DLL 的完整流程以 C 为例。假设我们有一个math_tools.dll导出一个double add(double a, double b)。先说 DLL 这边的导出。在 Visual Studio 里新建一个动态链接库(DLL)项目在头文件里写#ifdef MATH_TOOLS_EXPORTS #define MATH_TOOLS_API __declspec(dllexport) #else #define MATH_TOOLS_API __declspec(dllimport) #endif MATH_TOOLS_API double add(double a, double b);源文件里实现#define MATH_TOOLS_EXPORTS #include math_tools.h double add(double a, double b) { return a b; }这里MATH_TOOLS_EXPORTS这个宏是 VS 创建 DLL 工程时自动定义的用来区分当前是在导出还是导入。构建成功后你会得到math_tools.lib和math_tools.dll两个文件——注意.lib不是静态库它只是个导入符号表实际代码在.dll里。然后回到调用方。如果你是隐式链接打开工程属性C/C - 常规 - 附加包含目录填上 DLL 头文件所在目录。链接器 - 常规 - 附加库目录填上.lib所在目录。链接器 - 输入 - 附加依赖项填入math_tools.lib。把math_tools.dll放到 exe 同目录或者放到系统 PATH 能搜到的地方。这样代码里直接#include math_tools.h然后用add(1.0, 2.0)即可。注意 x64 和 x86 的位数必须一致Release/Debug 的运行时库设置也要匹配否则会有一堆莫名其妙的链接错误。如果走显式加载则不需要链接器和包含目录的配置代码改成#include windows.h typedef double (*AddFunc)(double, double); double call_add(double a, double b) { HMODULE hMod LoadLibraryA(math_tools.dll); if (!hMod) { // 加载失败可以 GetLastError() 看原因 return 0.0; } AddFunc fp (AddFunc)GetProcAddress(hMod, add); if (!fp) { FreeLibrary(hMod); return 0.0; } double result fp(a, b); FreeLibrary(hMod); return result; }每一步都要判空LoadLibrary失败、GetProcAddress找不到符号都必须处理。这是显式加载的典型节奏热加载的所有代码都是在这个模式上做文章。2.3 踩过的坑调用约定与名称粉碎这个坑我必须单独拿出来说因为几乎每个从隐式链接转向显式加载的人都会踩。前面示例里add是 cdecl 调用约定这在 C 里编译后符号名会被粉碎name mangling变成类似?addYANNNZ的形式。你用GetProcAddress(hMod, add)去查大概率返回NULL。解决办法就是导出时加上extern C。让符号保持 C 风格的名字extern C MATH_TOOLS_API double add(double a, double b);这样GetProcAddress就能用字面名字add找到它了。但如果你的导出函数使用__stdcall调用约定Windows 还会在符号名后面加一个加参数字节数比如add16。C 里用extern C__stdcall导出时符号名同样会被修饰。最稳妥的做法是导出时用模块定义文件.def 文件显式指定导出名或者干脆在GetProcAddress里用add16这种修饰名。我个人强烈建议平台相关的接口层统一用extern C__cdecl别在调用约定上玩花活。另一个常见的坑是 CRT 和内存管理。DLL 内部用new分配的内存交给主程序用delete释放在 Debug 版里十有八九会崩——因为两边可能链接的是不同堆。解决方法是把创建/销毁对象也设计成接口的一部分让内存的分配和释放在同一侧完成。这也是后面热加载实战里的接口必须带CreatePlugin/DestroyPlugin两个工厂函数的原因希望大家现在就记住这个原则。3. 热加载的核心机制与实现路径3.1 卸载、重载的真正含义从 API 层面看Windows 热加载的主角只有三个LoadLibrary、GetProcAddress、FreeLibrary。每个 DLL 在被加载时系统会维护一个引用计数LoadLibrary一次计数加一FreeLibrary一次计数减一只有计数归零DLL 才真正从进程地址空间里卸载。这个引用计数概念是理解热加载的第一把钥匙。但真正卸载四个字远没有字面那么简单。DLL 被卸载意味着它内部所有全局对象、静态变量、注册的回调、申请的资源都要跟着销毁。C 里静态对象的析构会在DllMain收到DLL_PROCESS_DETACH时执行但如果你的 DLL 里还驻留着别的线程正在执行它的代码卸载就会变成灾难——线程下一步就要跳到一个已经不存在的代码地址上瞬间崩溃。更隐蔽的是DLL 里可能有自己的 CRTC 运行时有自己的errno、线程局部存储、堆状态。这些状态在进程启动时就加载和运行中途加载这两种场景下差异很大。中途卸载再重新加载本质上相当于在一个已经跑起来的进程里再启动一个模块这个模块需要重新初始化一切但外部环境的全局状态并不会自动清空。这就是热加载难的根源不是 API 不支持而是二进制模块自身的状态依赖远比想象中多。重载的时候DLL 内部会重新执行全局构造、执行DllMain主程序的GetProcAddress再拿到一组全新的函数指针。所以热加载的本质并不是原地更新而是旧模块退场新模块入场你要保证整个过程中没有任何代码继续持有旧的函数指针或旧的模块句柄。这个要求听起来很基础但恰恰是实际工程里最难保证的。3.2 在 C 里实现 DLL 热加载的基础代码虽然热加载难但基础实现框架并不复杂。我先给一个最朴素的 C 显式加载循环然后逐步解释它为什么是能跑的最小骨架#include windows.h #include cstdio typedef void (*InitFunc)(const char* path); typedef void (*ExecuteFunc)(void); int main() { HMODULE hMod NULL; InitFunc init NULL; ExecuteFunc exec NULL; // 1. 加载模块 hMod LoadLibraryA(worker.dll); if (!hMod) return -1; // 2. 解析导出函数 init (InitFunc)GetProcAddress(hMod, init_module); exec (ExecuteFunc)GetProcAddress(hMod, execute); if (!init || !exec) { FreeLibrary(hMod); return -1; } // 3. 使用模块 init(C:/config/model.bin); exec(); // 4. 热卸载不再使用后再 FreeLibrary // 注意这里如果有其他线程正在调用 exec必须先保证它们退出 FreeLibrary(hMod); // 5. 等待片刻后重新加载新版本 worker.dll // 此时文件已被替换为最新版本 hMod LoadLibraryA(worker.dll); ... }这段代码的骨架是加载 - 解析 - 使用 - 卸载 - 再加载。但工程上必须给它加很多保护线程同步、句柄引用计数、模块版本校验、异常处理。比如你在第 4 步FreeLibrary的时候必须确认没有其他线程正趴在这个 DLL 的函数里执行否则就是经典的卸载了一个正在被调用的模块崩溃。实际操作中我会把热加载封装成一个ModuleManager类内部用std::shared_ptrvoid管理句柄用std::atomicbool标记模块是否可用再配合读写锁保证新模块加载和旧模块卸载的串行化。不要觉得这是小题大作——我在生产环境里见过太多裸用 LoadLibrary 导致随机崩溃的案例原因全是卸载时机没控制好。3.3 为什么热加载这么难全局状态与资源泄漏先说一个很多人没意识到的事实热加载真正难的从来不是加载/卸载本身而是模块内部的全局状态清理。一个 C DLL 里哪怕只有一个静态局部变量比如const std::string get_name() { static std::string name old; return name; }当这个 DLL 被FreeLibrary卸载时name这个全局对象会被析构。如果外面还有一份引用比如某些缓存里存了get_name()返回的指针这个引用就成了悬垂指针。如果你看不到这一层就会觉得崩溃毫无规律某个对象在模块卸载前一切正常卸载后一访问就炸。第二个大坑是跨模块内存分配。比如 DLL 里new了一个对象返回给主程序主程序在热卸载之后才调用delete此时对象的析构函数已经不在进程地址空间里了——因为 DLL 已经卸载。轻则访问违例重则整个堆损坏。这就是为什么我在 2.3 里反复强调跨模块对象的创建和销毁必须由同一侧通常是插件 DLL 内部的工厂函数完成主程序只调用DestroyPlugin绝不直接delete。第三个坑是句柄和系统资源。DLL 里可能开了文件句柄、网络连接、GPU 资源、线程池。FreeLibrary不会帮你自动关闭这些资源只负责执行该模块的静态析构和DllMain里的清理逻辑。如果你的DllMain不写清理代码资源就会泄漏。这个问题在热加载场景会被无限放大因为热加载通常发生在长期运行的进程里泄漏一次不觉得泄漏一百次之后系统资源耗尽进程整体崩溃。所以设计可热加载模块时我强烈建议所有资源都归接口对象所有Release()里统一释放。DLL 内部不要有跨调用保持状态的全局单例除非你能证明它能在模块卸载时被完全清理。模块里不要自行创建线程需要异步逻辑时把开始/停止暴露成接口方法让主程序在卸载前统一关闭。4. 实战把 onnxruntime 动态库玩出热更新4.1 为什么要热加载 onnxruntimeonnxruntime以下简称 ORT是微软开源的推理引擎日常做 AI 部署的同学肯定非常熟悉。它本身以动态库形式分发Windows 上叫onnxruntime.dllLinux 上是libonnxruntime.so。这个 DLL 体量不小还依赖 CUDA、cuDNN、DirectML 等一堆底层库静态链接基本不现实大家都在用动态库方式集成。很多人的用法是项目启动时加载 ORT创建Ort::Session然后一直跑模型推理。模型要更新时就重建 Session加载新的.onnx文件。这个属于模型热更新OR DLL 本身不用动问题不大。但真实生产里还有另一类需求引擎本身要升级比如 ORT 从 1.15 升到 1.16或者为了修复某个算子 bug 换了一个自定义补丁版 ORT。麻烦在于进程是不能重启的而 ORT 的库文件已经被新版覆盖旧版还在内存里。你总不能把正在运行的模型推理停掉然后干瞪眼吧。这种场景下就必须做引擎级热加载——把承载 ORT 的整个模块做成可插拔的动态库主程序在流量低谷时把旧模块卸载、加载新模块、重新初始化。从部署角度看这个能力让升级推理引擎变成了一个运维动作而不是开发动作新版本 ORT 编译好替换插件 DLL 文件触发一次热加载服务自动切到新引擎整个过程用户无感。4.2 模型热更新与引擎热更新的区别这里必须分清楚两个层级很多人混在一起之后debug起来异常痛苦。第一层级是模型热更新ORM 会话Session的配置文件或者权重文件变了。比如你今天用yolov5s.onnx明天换成yolov5m.onnx推理服务只需要重新创建一个Ort::Session把新的模型文件路径传进去旧 Session 释放掉就行。这个过程不涉及动态库加载/卸载纯粹是对象级别的重建。第二层级是引擎热更新onnxruntime 本体这个 DLL 变了。这时旧的Ort::Session对象底层指向的是旧 ORT 模块里的代码必须把这个对象销毁干净然后卸载旧 DLL再加载新 DLL在新的地址空间里重新创建 Session。本质上就是把用 ORT 做推理这一整坨能力封装成一个独立的插件 DLL主程序只认识和这个插件之间的接口协议完全不直接依赖 ORT 任何符号。我见过很多团队搞模型热更新搞得很溜但一涉及到换引擎版本就全员重启服务就是因为架构上把 ORT 直接绑死在主程序进程里了。其实正确的做法是把 ORT 当成插件 DLL 的私有依赖永远不要让它出现在主程序的头文件里。主程序只需要知道IInferPlugin这个抽象接口至于这个插件底层是 ORT 还是 TensorRT 还是自家写的纯 C 推理根本不重要。这样你不仅能热加载 ORT还能在 ORT 和另一套推理引擎之间做故障切换。4.3 基于 onnxruntime 的推理插件热加载示例下面我给一个可以直接抄作业的框架。设计目标主程序能在不重启的情况下替换推理引擎插件 DLL包括插件内部使用的 onnxruntime DLL 版本。先定义接口头文件主程序和插件都要引用它// infer_plugin.h #ifndef INFER_PLUGIN_H #define INFER_PLUGIN_H #ifdef _WIN32 #define PLUGIN_API __declspec(dllexport) #else #define PLUGIN_API __attribute__((visibility(default))) #endif // 跨模块边界只使用 C 风格接口避免 ABI 问题 typedef struct InferResult { int class_id; float score; } InferResult; #ifdef __cplusplus class IInferPlugin { public: virtual ~IInferPlugin() {} virtual bool Init(const char* modelPath) 0; virtual InferResult Infer(float* input, int size) 0; virtual void Release() 0; }; #endif extern C { PLUGIN_API bool CreateInferPlugin(IInferPlugin** plugin); PLUGIN_API void DestroyInferPlugin(IInferPlugin* plugin); } #endif插件 DLL 内部实现接口包含 onnxruntime 的头文件和库依赖// ortor_plugin.cpp #include infer_plugin.h #include onnxruntime_cxx_api.h class OrtPlugin : public IInferPlugin { public: bool Init(const char* modelPath) override { env_ std::make_uniqueOrt::Env(ORT_LOGGING_LEVEL_WARNING, infer); session_ std::make_uniqueOrt::Session(*env_, modelPath, sessionOptions_); return session_ ! nullptr; } InferResult Infer(float* input, int size) override { // 组装输入 Tensor执行 session_-Run(...) // ... return {0, 0.98f}; } void Release() override { delete this; // 内存释放发生在 DLL 内部 } private: std::unique_ptrOrt::Env env_; std::unique_ptrOrt::Session session_; Ort::SessionOptions sessionOptions_; }; extern C { bool CreateInferPlugin(IInferPlugin** plugin) { *plugin new OrtPlugin(); return true; } void DestroyInferPlugin(IInferPlugin* plugin) { delete plugin; } }主程序的模块管理器做热加载切换void ReloadInferenceEngine() { // 1. 摘除业务流量暂停新的推理请求等待在途请求结束 g_requestQuiesce.store(true); // 2. 销毁当前插件实例 if (g_plugin) { DestroyInferPlugin(g_plugin); g_plugin nullptr; } // 3. 卸载旧插件 DLL旧 onnxruntime 随插件 DLL 一起退出进程 if (g_hModule) { FreeLibrary(g_hModule); g_hModule nullptr; } // 4. 安全替换磁盘文件新插件 DLL 已复制到位 // 这里可以用 先复制到临时文件再 MoveFileEx 加 MOVEFILE_REPLACE_EXISTING 保证原子性 // 5. 加载新插件 DLL g_hModule LoadLibraryA(ort_infer_plugin.dll); if (!g_hModule) { g_requestQuiesce.store(false); return; // 回到旧版本或报警 } // 6. 获取工厂函数创建插件实例重新初始化模型 auto createFn (CreatePluginFn)GetProcAddress(g_hModule, CreateInferPlugin); createFn(g_plugin); g_plugin-Init(latest_model.onnx); // 7. 恢复业务流量 g_requestQuiesce.store(false); }关键点在于ORT 的env_和session_生命周期完全限制在插件 DLL 内主程序不会持有任何 ORT 对象。插件 DLL 被卸载时env_和session_作为插件对象成员先被析构然后插件对象再从堆上释放随后整个 DLL 卸载ORT 的资源清理动作都发生在合法范围内不会出现跨模块释放。这个流程已经可以支撑生产环境的引擎热更新了。实际部署时每次发布都会生成一个带版本号的插件 DLL比如ort_infer_plugin_v1.16.dll用一个符号链接或配置文件指到当前版本。重载时先加载新版本 DLL 测试连通性测试通过再切流量老版本 DLL 保留一个窗口期随时可以回滚。5. 热加载的进阶实践与排查技巧5.1 常见问题速查表热加载的问题通常不是一步崩而是偶发崩、随机崩、只在客户现场崩。我整理了一份排查表每一条都是实测里见过的真实问题。现象直接原因排查方向LoadLibrary 返回 NULL错误码 126/127DLL 依赖的其他 DLL 找不到用 Dependency Walker 或 dumpbin /dependents 查看依赖检查 PATH、exe 目录、系统目录LoadLibrary 返回 NULL错误码 193位数不匹配x64 进程加载了 x86 DLL确认 exe 和 DLL 的 Platform 都是 x64且依赖全部匹配GetProcAddress 找不到符号没加 extern C或被调用约定修饰用 dumpbin /exports 查看实际导出名卸载 DLL 时崩溃模块内静态对象析构顺序问题或外部仍持有旧函数指针用FreeLibraryAndExitThread排查检查所有回调注册确保无线程在执行 DLL 代码文件被占用无法替换 DLL旧 DLL 还在进程里引用计数不为零确认没有GetProcAddress得到的函数指针残留确认子进程没有持有句柄重载后行为异常旧模块的全局状态没清干净审查 DLL 内所有 static/全局变量优先改用接口对象管理所有状态重载后内存持续增长每次热加载都泄漏资源每次重载前后抓快照对比重点看 DLL 是否注册了全局钩子或创建了常驻线程以上几个问题的共性就是你得先怀疑模块边界。热加载崩溃 90% 都发生在模块交接的那一瞬而不是模块自身逻辑正确性上。所以排查时先把业务线程停干净再卸载看崩不崩如果不崩就说明是竞态需要补齐同步机制。5.2 生产环境热加载的落地经验最后聊一点经验向的。热加载在 demo 里跑通很容易真正上生产有很多细节。第一双缓冲和原子替换。我强烈建议不要直接把worker.dll覆盖掉而是先写到临时文件名等卸载完成后再通过MoveFileEx加MOVEFILE_REPLACE_EXISTING一次性替换。这样即使新 DLL 有问题磁盘上还能留一份可回滚的旧版本。热加载失败时立刻重新加载旧版本 DLL业务侧完全无感。第二流量摘除要用优雅停止而不是强杀。具体来说就是置一个原子标志让新请求不再进入插件对已在执行中的推理请求设置一个合理的超时比如 5 秒等它结束。千万不要直接TerminateThread——那会把整个进程的堆锁和 CRT 状态搞坏后续任何malloc/new都可能死锁。我之前见过一个团队在热更新时强杀线程结果模块卸载没问题但整个进程从此进入每隔几分钟随机卡死的诡异状态。第三版本标记和健康检查要配套。每个插件 DLL 导出一个GetPluginVersion()主程序加载后先校验版本号再加载模型最后跑一次冒烟推理比如用一个固定的输入向量检查输出是否在合理范围内全部通过才切流量。这一步看起来笨实际上能挡住大量依赖缺失但 LoadLibrary 碰巧成功的问题。第四注意平台差异。Windows 下 DLL 加载后文件会被映射进地址空间即使逻辑上卸载了某些杀毒软件或文件监控工具也可能短暂持有句柄所以替换 DLL 失败时不要立即放弃重试几次可能就成功了。Linux 下.so的处理逻辑类似但不会出现 Windows 那种文件被占用的锁问题不过要额外注意.so内部的构造函数、析构函数在dlclose时的执行顺序以及旧版本.so的内存未释放问题。根据我个人的项目经验热加载这种东西其实设计比实现重要。你把接口边界定义清楚把资源生命周期全部收敛到模块对象里后面所有的加载、卸载、替换都是顺理成章的事反过来如果一开始就没想清楚边界强行用LoadLibrary做热更新就是把一个炸弹埋进了线上服务今天不炸明天炸。每次升级 ORT 这类重量级动态库时我都庆幸当初把插件边界划得足够干净——因为真正到了凌晨三点需要紧急升级引擎的时候需要的不是写代码的勇气而是架构上提前留好的那扇门。