MediatR 初始化必须注册 IMediator 接口
不注册
IMediator就直接注入会报
InvalidOperationException: Unable to resolve service for type 'MediatR.IMediator'。ASP.NET Core 6+ 默认用
AddMediatR()扩展方法，但要注意参数——它默认只扫描当前程序集，跨类库时得显式传入程序集： 单项目：直接
services.AddMediatR(cfg => cfg.RegisterServicesFromAssembly(typeof(Program).Assembly));命令/查询/处理逻辑在独立类库中：必须把对应程序集加进去，比如
AddMediatR(typeof(CreateUserCommandHandler).Assembly)别漏掉
using MediatR;，否则
AddMediatR方法不可见
IRequest 和 IRequest 的选择取决于是否需要返回值
写请求类时，用
IRequest表示“只发不收”（如发送邮件、触发日志），用
IRequest<tresponse></tresponse>表示“发完要等结果”（如查用户、生成订单号）。选错会导致编译失败或运行时报
Cannot convert lambda expression类型错误： 无返回值示例：
public record CreateUserCommand(string Name) : IRequest;有返回值示例：
public record GetUserQuery(Guid Id) : IRequest<userdto>;</userdto>Handler 类必须严格匹配泛型参数：
public class GetUserQueryHandler : IRequestHandler<getuserquery userdto></getuserquery>
CQRS 分离的关键不是命名，而是职责和生命周期
很多人以为只要把类名写成 “Query/Command” 就算 CQRS，其实核心是：查询不改状态、命令不返回领域数据、读写模型物理隔离（哪怕一开始共用 EF Core DbContext）。常见踩坑点：
在IRequestHandler<trequest tresponse></trequest>里调用
_context.SaveChanges()—— 这属于命令逻辑，不该出现在 Query Handler 中 Query Handler 返回
Entity而非 DTO，导致序列化时触发 EF 延迟加载或循环引用 所有 Handler 都用同一个 DbContext 实例（Scoped 生命周期），但没做读写分离配置，缓存/事务行为容易互相干扰
MediatR 管道行为（Pipeline Behavior）适合横切逻辑，但别滥用
比如日志、验证、权限检查，用
IPipelineBehavior<trequest tresponse></trequest>比在每个 Handler 里重复写更干净。但要注意执行顺序和异常传播： 多个 Behavior 按注册顺序“套娃”，先注册的在外层；想让验证最先执行，就第一个
AddTransient在 Behavior 中 throw 异常会中断后续 Handler，但
ValidationException不该被吞掉，否则前端拿不到具体错误字段 不要在 Behavior 里 new DbContext 或手动管理事务——它可能跨多个 Handler，而事务应由最外层命令控制 CQRS 的真正复杂点不在 MediatR 怎么配，而在读写模型的数据一致性策略：是用事件总线最终一致，还是同步双写，抑或共享数据库但分 Schema。这些决策会影响 Handler 里要不要发事件、要不要加重试、要不要补偿逻辑——而 MediatR 本身只负责调用链路，不解决这些问题。
