ASP.NET Core 默认能扛住多少并发请求？
不调优的 ASP.NET Core 应用在 Linux + Kestrel 下，单实例通常能稳定处理
3000–5000并发连接（非每秒请求数），但实际吞吐量取决于业务逻辑：纯 API 返回 JSON 且无 IO 等待时，QPS 可达
15k+；一旦涉及数据库查询、HTTP 外部调用或大对象序列化，QPS 可能跌到
200–800。Kestrel 本身不是瓶颈，瓶颈常出在
ThreadPool配置、
HttpClient复用、JSON 序列化和数据库连接池上。
必须改的三个 Kestrel 和线程池配置
默认配置在高并发下会因线程饥饿或连接排队导致延迟飙升。关键项不是“越多越好”，而是匹配硬件与负载特征：
ThreadPool.SetMinThreads(100, 100)—— 避免初期线程创建延迟，尤其在 Linux 上默认最小工作线程仅
8；但设太高会浪费内存，建议按 CPU 核数 × 10 初设 Kestrel 的
Limit.MaxConcurrentConnections设为
null（不限制）或至少
5000；默认是
null，但某些反向代理（如 Nginx）可能限制了 upstream 连接数，需同步检查
WebHostBuilder.ConfigureKestrel(...)中启用
AllowSynchronousIO = false（默认已禁用），强制所有 I/O 走 async，避免线程被
ReadAsStringAsync()这类同步方法阻塞
var builder = WebApplication.CreateBuilder(args);
builder.WebHost.ConfigureKestrel(serverOptions =>
{
serverOptions.Limits.MaxConcurrentConnections = null;
serverOptions.Limits.MaxRequestBodySize = 10 * 1024 * 1024; // 按需调大
});
// 启动前调用
ThreadPool.SetMinThreads(64, 64); // 示例：8 核机器HttpClient 不复用 = 并发杀手
每次 new
HttpClient()会新建 TCP 连接池，耗尽端口（Linux 默认
ephemeral port range约 28K）、触发 TIME_WAIT 堆积，500+ 并发就可能报
SocketException: Too many open files。正确做法只有一种： 全局注册
IHttpClientFactory，用
builder.Services.AddHttpClient()注册命名/类型化客户端 Controller 或 Service 中通过构造函数注入
IHttpClientFactory，再用
CreateClient("name") 获取实例 —— 它内部自动复用连接、处理 DNS 刷新、支持 Polly 熔断
绝对不要在 using 块里 new HttpClient，也别把它声明为 static 字段（DNS 变更无法感知，连接长期不释放）
// Program.cs
builder.Services.AddHttpClient<IUserService, UserService>()
.ConfigurePrimaryHttpMessageHandler(() => new HttpClientHandler
{
MaxConnectionsPerServer = 100 // 关键：提高单服务连接上限
});JSON 序列化和数据库访问的隐性开销
高并发下，
System.Text.Json默认行为仍可能拖慢响应：深度嵌套对象、大量字符串拼接、未关闭
WriteIndented = true。数据库侧常见问题是连接池耗尽或命令超时未设。 API 返回 DTO 时，禁用
JsonSerializerOptions.WriteIndented（默认 false，但有人显式设为 true）；对含敏感字段的类型，用
[JsonIgnore]比运行时条件判断快
DbContext必须作用域生命周期（
AddDbContextPool），池大小按压测结果调：默认
1024，但若平均请求 DB 耗时
，可降到 <code>256减少内存占用 所有
async数据库调用必须配
CommandTimeout，例如
context.Database.GetDbConnection().ConnectionTimeout不起作用，得在
OnConfiguring里设
optionsBuilder.UseSqlServer(connStr, o => o.CommandTimeout(30))
真正卡住高并发的，往往不是框架上限，而是某次
await dbContext.Users.ToListAsync()没加
AsNoTracking()，或前端反复发未带 ETag 的全量 GET 请求——这些细节比调 Kestrel 参数影响更大。
