EF Core超时需分三类处理：命令超时（CommandTimeout）控制SQL执行时间，可全局、连接字符串或运行时设置；连接超时（Connect Timeout）仅限连接阶段，须在连接字符串中配置；大结果集卡在结果消费阶段，应结合CancellationToken、分页、投影和AsNoTracking优化。
EF Core超时错误通常不是单一原因导致的，而是命令执行、连接建立、结果读取三个环节中某一个卡住了。解决的关键是分清类型、精准设值，而不是盲目拉长超时时间。
命令超时（CommandTimeout）怎么设才有效
这是最常配置也最容易误解的超时——它只控制 SQL 语句在数据库里“执行完”的时间，不包括网络传输、结果反序列化或内存处理。
- 全局设置（推荐用于多数场景）：在
OnConfiguring中统一指定
protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
{
optionsBuilder.UseSqlServer(“Server=.;Database=MyDb;”, options => options.CommandTimeout(120));
}
- 连接字符串内设（简单直接，适合开发/测试环境）：
Command Timeout=120; - 运行时动态调整（如某个报表查询特别慢）：
context.Database.SetCommandTimeout(300); - 注意：设为
0表示无限等待（不建议生产环境使用）
连接超时（Connect Timeout）别和命令超时搞混
它只管“连上数据库”这一步，比如网络抖动、SQL Server 服务没启、防火墙拦截等场景。一旦连接成功，这个超时就失效了。
- 必须通过连接字符串设置，EF Core 不提供 API 动态修改
- 典型写法：
Server=.;Database=MyDb;Connect Timeout=30; - 一般保持默认 15 秒即可；若部署在弱网环境（如云函数冷启动），可适当加到 30 秒
大结果集超时？命令超时救不了你
当查询返回几十万行数据时，CommandTimeout 到期前 SQL 已执行完，但 ToListAsync() 还在拼命读、映射、分配内存——这时真正卡住的是“消费结果”阶段。
- 正确做法是用异步取消令牌限制整体耗时
var cts = new CancellationTokenSource(TimeSpan.FromSeconds(60));
var list = await context.Orders.ToListAsync(cts.Token);
- 配合分页（
Skip/Take）、投影（Select只取需要字段）、流式读取（AsNoTracking()）效果更明显 - 如果必须导出全量，考虑改用
SqlDataReader手动流式处理，绕过 EF 的对象映射开销
迁移（Migrations）超时怎么办
执行 dotnet ef database update 时卡住，常见于加索引、重建大表、数据迁移脚本复杂等情况。此时不是代码问题，而是迁移工具本身超时了。
- EF Core 7+ 支持在
Migrations/Configuration.cs构造函数中设全局迁移超时
public Configuration() { CommandTimeout = 1800; // 单位：秒，即30分钟 }
- 或者临时用命令行参数：
dotnet ef database update --command-timeout 1800 - 根本解法仍是优化迁移脚本：拆分大操作、避免锁表、提前建好索引再灌数据
基本上就这些。超时不是越设越大越好，而是要先定位卡在哪一环，再选对方法。多数线上问题，其实是查询没走索引、没分页、或一次性加载太多实体导致的。