Wolverine默认动态生成模式为什么会让首次请求变慢？
因为Wolverine在应用启动时才用Roslyn实时编译消息处理器调用链，包括中间件织入、序列化适配器、HTTP端点绑定等——这相当于把“编译+JIT”搬到了运行时。冷启动时，
Handle方法第一次被调用前，你可能看到200–800ms的延迟，尤其在Serverless或K8s Pod快速伸缩场景下特别明显。 现象：API首次响应超时、Health Check失败、CI/CD部署后自动测试偶发失败 解决：改用静态代码生成，在构建阶段预编译所有消息管道：
services.AddWolverine(opts => { opts.CodeGeneration.Mode = CodeGenerationMode.Static; });
注意：Static模式要求项目启用源生成（
<enabledefaultitems>false</enabledefaultitems>需关闭），且必须确保所有
ICommand/
IEvent及其
Handler类可被Roslyn分析到（不能藏在
internal程序集或反射加载的插件中）
为什么注入AppDbContext
进Handler会导致并发写入异常？
Wolverine默认为每个消息创建独立作用域（Scope），但
AppDbContext若注册为
Scoped，在并行处理多个命令时，多个
Handle方法会拿到不同实例——看似安全，实则埋雷：EF Core的
ChangeTracker不是线程安全的，而Wolverine的默认调度器可能复用线程（尤其在
ThreadPool模式下）。一旦两个Handler在同一线程先后执行，
_dbContext实例虽不同，但底层
DbConnection可能被复用，引发
InvalidOperationException: A second operation started on this context before a previous operation completed。 正确做法：始终用
AddDbContextFactory<appdbcontext></appdbcontext>注册，并在Handler内按需创建上下文：
private readonly IDbContextFactory<AppDbContext> _contextFactory;<br>public async Task<ItemCreated> Handle(CreateItemCommand cmd)<br>{<br> await using var ctx = await _contextFactory.CreateDbContextAsync();<br> ctx.Items.Add(new Item(cmd.Name, cmd.Price));<br> await ctx.SaveChangesAsync();<br> return new ItemCreated(...);<br>}
别碰AddDbContext<appdbcontext>(ServiceLifetime.Scoped)</appdbcontext>+ Wolverine组合——它在逻辑上自洽，但运行时极易因调度细节翻车
dotnet add package Wolverine.EntityFrameworkCore
到底要配什么才能让事务自动传播？
这个包本身不自动开启事务；它只提供
DbContext集成钩子。事务是否生效，取决于你如何声明Handler和配置Wolverine的
UnitOfWork行为。 必须显式标记Handler支持事务：
[Transactional] // ← 关键！没有这行，SaveChangesAsync()不会包裹在TransactionScope里<br>public class CreateItemHandler { ... }
还要确保Wolverine启用了EF Core事务拦截：services.AddWolverine(opts =><br>{<br> opts.Policies.AutoApplyTransactions(); // ← 这行让[Transactional]真正起效<br>});
坑点：若Handler同时处理多个命令（比如用IMessageBus发布事件），事务只覆盖当前命令的DB操作，发布的事件不会回滚——Wolverine不提供跨消息的分布式事务，别指望它替代Saga
Handler里调用IMessageBus
发事件，为什么测试时收不到？
因为Wolverine默认使用内存传输（InMemoryTransport），而单元测试常直接new Handler调用
Handle()，绕过了Wolverine的消息调度管道——
IMessageBus此时是空实现，发出去的事件根本没进队列。 真测：用
Wolverine.Testing的
Scenario跑端到端流程：
await theSystem.Scenario(x =><br>{<br> x.Post.Input(new CreateItemCommand("test", 9.9m));<br> x.ShouldHavePublished<ItemCreated>();<br>});
假测（仅验证逻辑）：把IMessageBus抽成接口，测试时用Moq模拟
SendAsync，但注意——这测不出事务边界、重试策略、死信投递等真实行为 最常漏的：忘了在
Program.cs里调用
UseWolverine()，导致
IMessageBus解析为空实例，发事件静默失败 Wolverine的高性能不是靠“开箱即用”，而是靠你主动关掉动态生成、管住DbContext生命周期、手动标注事务、用对测试方式——这些地方一松懈，它就退回普通DI容器水平。
