EF Core 5环境下应当使用AddDbContext还是AddDbContextPool？

1. 首次调用接口慢、后续提速的核心原因 #

EF Core内置全局查询编译缓存，首次触发某业务逻辑对应的EF查询时，框架需要将LINQ表达式编译为可执行的SQL语句，这个过程开销较高，编译后的结果会被全局缓存，和具体的DbContext实例生命周期无关。后续只要是结构一致的查询（仅参数值不同），会直接复用缓存的编译结果，所以速度明显提升。你遇到的首次调用耗时高就是查询首次编译的开销，和Swagger本身无关。

2. DbContext Pooling能否避免重复编译EF查询？ #

不能。
EF Core的查询编译缓存是全局共享的，默认情况下只要你没有手动关闭查询缓存，就算每次请求结束销毁DbContext实例，缓存的编译结果也不会被清除，不需要依赖DbContext Pooling来保留编译结果。
DbContext Pooling的核心作用是复用DbContext实例，减少每次请求新建、销毁DbContext实例的开销，这部分开销本身远低于查询首次编译的开销，所以它不会解决你遇到的首次调用慢的问题，但在高并发、高频请求的场景下，可以降低整体的CPU占用，小幅提升接口吞吐量。

3. 早期关于DbContext Pooling的回答是否适用于EF Core 5.0及以上稳定版？ #

适用。从EF Core 2.0首次推出DbContext Pooling功能到最新稳定版，该功能的核心设计逻辑没有发生变更，查询缓存全局独立、DbContext Pooling仅负责实例复用的底层机制一直保留，早期回答的核心结论仍然有效。

针对性性能优化建议 #

• 针对首次调用慢的问题，可以在应用启动完成后增加预热逻辑，主动调用一次热点业务对应的查询，提前触发EF查询编译，将结果存入缓存，避免真实用户请求遇到首次编译的高耗时。
• 如果你的SPA项目排除首次编译问题后仍然调用偏慢，先检查是否存在动态拼接LINQ导致查询结构每次变化、无法命中全局编译缓存的情况，尽量保证相同业务逻辑的查询结构一致，仅通过参数传递变化的条件。
• 对于高频调用的复杂查询，可以手动使用EF.CompileAsyncQuery显式预编译查询，进一步提升查询执行效率。
• 如果业务场景允许，优先使用非跟踪查询（AsNoTracking()），减少EF状态管理的开销。
• 可以开启DbContext Pooling，降低高并发场景下的实例化开销，配置方式为在Program.cs中将AddDbContext替换为AddDbContextPool即可，无需修改其他业务代码。

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