MediatR中的类型缓存问题与插件热卸载方案

在基于MediatR实现的插件化架构中，开发者Ralf1108遇到了一个典型的热卸载难题。当使用MediatR的Publish方法时，系统会在内部静态缓存中保留NotificationHandlerWrapper实例，导致插件程序集无法被正确卸载。

问题本质分析

MediatR为了提高性能，在内部维护了一个静态的ConcurrentDictionary<Type, NotificationHandlerWrapper>缓存。这个设计在常规场景下非常有效，但在插件热加载/卸载场景中却成为了障碍。当插件定义了自己的消息类型并注册了对应的处理器后，这些类型信息会被MediatR缓存，从而在插件试图卸载时仍然保持着对程序集的引用。

技术细节剖析

NotificationHandlerWrapper是MediatR内部用于封装通知处理器的包装类。每次调用Publish方法时，系统会：

1. 检查缓存中是否已有对应类型的包装器
2. 如果没有则创建新的包装器并缓存
3. 使用缓存的包装器执行实际的消息分发

这种缓存机制在静态程序集加载场景下没有问题，但在使用AssemblyLoadContext进行动态加载/卸载时，会导致插件程序集无法被垃圾回收。

解决方案探讨

目前官方没有提供直接清除缓存的方法，开发者不得不使用反射来清除内部缓存字段。虽然这种方法可行，但存在几个问题：

1. 反射访问私有字段破坏了封装性
2. 依赖于MediatR内部实现细节，未来版本变更可能导致代码失效
3. 缺乏线程安全保障

更优雅的解决方案应该是MediatR提供官方的缓存清除API，例如：

public interface IMediatorCacheManager
{
    void ClearNotificationHandlerCache();
}

最佳实践建议

对于需要实现插件热卸载的场景，开发者可以考虑以下方案：

1. 为每个插件创建独立的AssemblyLoadContext
2. 在每个LoadContext中创建独立的MediatR实例
3. 卸载插件时直接释放整个LoadContext
4. 如果必须共享MediatR实例，则在卸载前手动清除缓存

总结

MediatR的静态缓存设计在插件化架构中带来了挑战。理解这一机制对于构建可热插拔的系统至关重要。虽然目前需要通过反射解决，但这个问题也提示我们在设计框架时需要考虑到动态加载场景的需求。未来版本的MediatR若能提供更灵活的缓存管理机制，将大大简化插件化架构的实现。