wolverine默认动态生成模式使首次请求变慢，因其在启动时用roslyn实时编译消息处理器调用链，导致冷启动延迟200–800ms；应改用静态代码生成并确保源生成启用。
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解析为空实例，发事件静默失败
