真正能热加载+热卸载的只有assemblyloadcontext（alc），且必须设iscollectible:true；其他方式如assembly.loadfrom加载的程序集永久驻留内存，无法卸载。
真正能热加载 + 热卸载的，只有 AssemblyLoadContext（ALC），且必须设 isCollectible: true；其他方式（如 Assembly.LoadFrom）加载的程序集永远驻留内存，卸载无效。
为什么 AssemblyLoadContext.LoadFromAssemblyPath 直接调用会静默失败或抛 FileNotFoundException
这不是路径写错，而是 ALC 默认不解析插件依赖链。比如你只传入 MyPlugin.dll，但它依赖 Newtonsoft.Json.dll 或某个特定版本的 Microsoft.Extensions.DependencyInjection.dll，ALC 会 fallback 到 AssemblyLoadContext.Default 去找——而那里没有，于是报“找不到某某内部类型”，不是插件本身的问题。
- 必须重写
AssemblyLoadContext.Load方法，在其中拦截所有依赖请求，并统一从插件目录加载对应 DLL - 插件发布必须用
dotnet publish -r win-x64 --self-contained false，确保生成.deps.json和.runtimeconfig.json - 别只复制单个 DLL —— 整个发布输出目录（含
.deps.json、.runtimeconfig.json、所有依赖 DLL）一起拷进插件目录 - 若插件引用了宿主也引用的 NuGet 包（如
Serilog），需确保双方版本完全一致，否则 ALC 会因签名冲突拒绝加载
如何让插件类型在宿主中安全使用，避免 InvalidCastException 或 Cannot load type from assembly because it is not in the same context
跨 ALC 的类型无法直接强制转换或 new 实例。哪怕 IPlugin 接口定义一模一样，只要它分别来自两个不同 ALC，CLR 就认为是两个类型。
- 接口必须定义在**独立共享契约程序集**（如
PluginContract.dll），且该程序集只能由AssemblyLoadContext.Default加载（即宿主启动时就LoadFromAssemblyPath进来） - 插件项目必须引用这个契约程序集（不能引用宿主项目，也不能把接口写在宿主里）
- 创建插件实例后，必须通过契约接口接收，例如：
IPlugin plugin = (IPlugin)assembly.CreateInstance("MyPlugin.PluginImpl"); - 禁止返回
List<t></t>、string、自定义类等托管对象——如果必须传数据，走 JSON 序列化，或定义只含get属性的简单类型
卸载失败的常见原因和排查要点
调用 context.Unload() 后内存没释放、DLL 文件仍被锁住、下次加载报“文件正被另一进程使用”——这些都不是 ALC 本身坏了，而是上下文还有残留引用没清理干净。
- 卸载前必须确保：所有插件对象实例已置为
null，所有事件订阅已取消，所有后台线程已退出（包括Task.Run、Timer、BackgroundService） - 不能在插件代码中注册到宿主的全局事件（如
AppDomain.CurrentDomain.UnhandledException），否则 ALC 引用链无法切断 - 调用
context.Unload()后，要主动触发一次 GC（GC.Collect(); GC.WaitForPendingFinalizers();），否则卸载可能延迟生效 - 检查是否误用了
AssemblyLoadContext.GetLoadContext(assembly).ExecuteInLoadContext但闭包里捕获了默认上下文的变量——这会导致隐式引用泄漏
最易被忽略的是：插件目录下多了一个未声明的 DLL（比如调试时手动丢进去的旧版依赖），它会被 ALC 自动尝试加载，一旦失败就会中断整个上下文初始化流程，且错误堆栈极不直观。建议每次加载前先校验插件目录的 .deps.json 与实际文件清单是否一致。
