CompositionContainer 初始化失败常因类型反射加载失败，主因是程序集版本/框架不匹配、DLL未显式加载或缺失部署依赖；Import为null则多因Catalog未包含对应Export、路径错误或契约不一致。
为什么 CompositionContainer 初始化失败常报“Unable to load one or more of the requested types”
当你在 C# 中使用 MEF 框架遇到此错误时，通常不是框架本身的问题，而是类型反射加载环节出现了故障。容器在运行时无法定位到你所定义的类型。这主要源于以下几种典型情况：程序集版本不匹配、目标框架不一致（例如插件基于 .NET 5 编译，而宿主程序运行在 .NET 6 环境），或者包含目标类型的 DLL 未被正确加载到当前应用程序域中。
- 确保程序集显式可用：所有参与组合的部件，其所在的程序集都必须通过
Assembly.LoadFrom等方法显式加载，或确保它们已存在于AppDomain.CurrentDomain.GetAssemblies()的列表中。 - 警惕未部署的依赖：如果你的
[Export]类型引用了某些仅在开发环境中存在的 NuGet 包（如特定的调试工具包），而这些依赖未随主程序一同部署，运行时将无法找到它们。 - 善用异常诊断：一个高效的排查技巧是使用
try/catch捕获ReflectionTypeLoadException，并检查其LoaderExceptions属性。它能精确指出具体是哪个类型加载失败，是定位问题的关键工具。
Import 属性为 null？检查 ComposablePartCatalog 是否包含对应 Export
一个常见的误区是认为 MEF 会自动扫描整个应用程序来寻找导出部件。实际上，MEF 只会从你显式提供的 ComposablePartCatalog（目录）中进行查找。如果你使用了 DirectoryCatalog，但插件 DLL 存放路径错误、文件扩展名不符、甚至文件被安全软件锁定，都可能导致 Import 属性返回 null。
- 确认目录内容：直接检查
catalog.Parts.Count()。如果结果为 0，基本可以确定是路径错误或程序集加载失败。 - 注意文件类型：
DirectoryCatalog默认仅识别.dll文件，对于.exe或无扩展名的文件，它不会进行加载。 - 别忘了主程序集：如果导出类定义在主执行程序集内，务必使用
new AssemblyCatalog(Assembly.GetExecutingAssembly())将其添加到目录中。 - 契约必须严格匹配：导入属性上必须标注
[Import]，且其类型签名必须与[Export]的定义完全一致，包括命名空间。当使用接口导出时，如果指定了契约名称（contract name），那么导入时也必须使用相同的契约名称才能成功匹配。
用 ExportFactory 替代直接 Import 实现延迟创建与生命周期控制
直接使用 [Import] 存在一个局限：对象会在组合容器构建完成时立即实例化，这使你无法控制创建时机，也难以管理其生命周期和资源释放。而 ExportFactory 正是为解决此问题而设计的。它提供了 CreateExport() 方法，允许你在需要时才创建实例，每次调用都会生成一个新的实例，并支持通过 Dispose() 进行显式释放。
- 导出端配置：在导出类上，通常需要这样标注：
[Export(typeof(IMyService))][PartCreationPolicy(CreationPolicy.NonShared)]。 - 导入端声明：不再直接导入服务，而是导入其工厂：
[Import] public ExportFactory。ServiceFactory { get; set; } - 使用模式：实际使用时，遵循标准模式：
using var export = ServiceFactory.CreateExport(); var service = export.Value;。 - 关键提醒：如果导出类实现了
IDisposable，并且创建策略是NonShared（非共享），那么务必在不再需要时手动调用export.Dispose()，否则可能导致实例泄漏和资源未释放。
.NET Core/.NET 5+ 中为什么 System.ComponentModel.Composition 不推荐继续用
对于现代 .NET 项目，需要明确：原生的 MEF（即 System.ComponentModel.Composition 命名空间下的 API）在 .NET Core 及更高版本中，更多是作为兼容层存在，功能上存在诸多限制。例如，它不支持 DirectoryCatalog 的热重载、处理跨平台路径时可能行为不一致、反射机制也与传统的 .NET Framework 版本有所差异。更重要的是，微软已将其标记为“legacy”（遗留技术）。因此，新项目应当考虑迁移。
- 主流替代方案：首选是转向
Microsoft.Extensions.DependencyInjection结合自定义的插件加载逻辑。 - 社区 MEF2：另一个选择是使用社区维护的
System.Composition（常被称为 MEF2）。它是一个轻量级替代品，API 设计相似但并不兼容旧版 MEF，需要替换命名空间，并使用ContainerConfiguration来构建容器。 - MEF2 的优势：它提供了更精细的控制，例如通过
AssemblyPartDiscovery可以更精确地筛选类型，避免意外加载测试类或内部工具类。 - 注意差异：MEF2 没有内置的
Lazy自动包装机制。如果需要延迟加载，需手动用Lazy包裹ExportFactory来实现。
总而言之，MEF 的许多问题都源于对“自动化”的过度依赖。它看似自动完成了所有依赖注入，但实际上，每一处连接是否畅通、接口是否完全匹配，都需要开发者仔细确认。尤其是在跨程序集的复杂场景下，类型加载、生命周期管理和契约匹配这三个核心环节，任何一个出现偏差，都可能导致 Import 属性静默地变为 null，而不会抛出明确的错误信息。这正是使用 MEF 进行插件式开发时需要高度警惕的地方。
