MediatR 初始化必须注册 IMediator 接口，否则注入时抛 InvalidOperationException；ASP.NET Core 6+ 用 AddMediatR()，跨类库需显式传入程序集；IRequest 用于无返回值操作，IRequest<TResponse> 用于需返回值场景；Handler 必须严格匹配泛型参数；CQRS 核心是职责与模型隔离，非仅命名；管道行为适合横切逻辑但需注意执行顺序与异常处理；数据一致性策略才是 CQRS 复杂所在。
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<TResponse> 的选择取决于是否需要返回值
写请求类时，用 IRequest 表示“只发不收”（如发送邮件、触发日志），用 IRequest<TResponse> 表示“发完要等结果”（如查用户、生成订单号）。选错会导致编译失败或运行时报 Cannot convert lambda expression 类型错误：
- 无返回值示例：
public record CreateUserCommand(string Name) : IRequest; - 有返回值示例：
public record GetUserQuery(Guid Id) : IRequest<UserDto>; - Handler 类必须严格匹配泛型参数：
public class GetUserQueryHandler : IRequestHandler<GetUserQuery, UserDto>
CQRS 分离的关键不是命名，而是职责和生命周期
很多人以为只要把类名写成 “Query/Command” 就算 CQRS，其实核心是：查询不改状态、命令不返回领域数据、读写模型物理隔离（哪怕一开始共用 EF Core DbContext）。常见踩坑点：
- 在
IRequestHandler<TRequest, TResponse>里调用_context.SaveChanges()—— 这属于命令逻辑，不该出现在 Query Handler 中 - Query Handler 返回
Entity而非 DTO，导致序列化时触发 EF 延迟加载或循环引用 - 所有 Handler 都用同一个 DbContext 实例（Scoped 生命周期），但没做读写分离配置，缓存/事务行为容易互相干扰
MediatR 管道行为（Pipeline Behavior）适合横切逻辑，但别滥用
比如日志、验证、权限检查，用 IPipelineBehavior<TRequest, TResponse> 比在每个 Handler 里重复写更干净。但要注意执行顺序和异常传播：
- 多个 Behavior 按注册顺序“套娃”，先注册的在外层；想让验证最先执行，就第一个
AddTransient - 在 Behavior 中 throw 异常会中断后续 Handler，但
ValidationException不该被吞掉，否则前端拿不到具体错误字段 - 不要在 Behavior 里 new DbContext 或手动管理事务——它可能跨多个 Handler，而事务应由最外层命令控制
