MediatR是否扫描项目类匹配请求？相关机制技术问询

问题1：上述流程理解是否正确？ #

正确，完整流程如下：

• 通过app.MediateGet<ExampleRequest>("example/{name}")扩展方法，将HTTP GET路由example/{name}与ExampleRequest请求类型绑定
• ExampleRequest作为POCO会自动绑定URL中的name参数
• 最终由实现IRequestHandler<ExampleRequest, IResult>接口的处理器类处理请求，并返回ASP.NET Core标准的IResult结果

问题2a：MediatR未注册处理器类时，如何找到ExampleHandler？是否会扫描项目所有类匹配？ #

MediatR不会自动查找未注册的处理器，必须通过注册告知容器哪些类是处理器：

• 常规做法是用services.AddMediatR(cfg => cfg.RegisterServicesFromAssemblyContaining<ExampleRequest>())，它会扫描指定程序集（包含ExampleRequest的程序集）内所有实现IRequestHandler<>/INotificationHandler<>的类并自动注册
• 不会扫描所有项目的类，只会扫描你配置的程序集范围
• 如果完全未做任何处理器注册，运行时调用请求会抛出InvalidOperationException，提示找不到对应请求的处理程序

问题2b：若存在两个匹配的处理器类，会如何处理？ #

MediatR遵循命令模式的单处理原则，一个请求类型只能对应一个处理器：

• 批量注册时，MediatR会检测到重复的处理器实现，直接在启动阶段抛出注册异常
• 若手动重复注册两个处理器，依赖注入容器会返回最后注册的实例，但这属于错误用法，违背MediatR的设计初衷，会导致不可预期的行为

问题2c：是否可通过注册处理器类提升查找效率并避免重复匹配？ #

可以，注册处理器有以下好处：

• 提升效率：手动注册或指定程序集批量注册，避免了无意义的程序集扫描，减少应用启动时的开销
• 避免重复匹配：明确的注册逻辑能在启动阶段就检测到重复的处理器实现，提前暴露错误，避免运行时出现异常

内容的提问来源于stack exchange，提问作者David Thielen