用 async
/await
替换同步 I/O 操作
Web API 的并发瓶颈常来自阻塞式 I/O，比如
HttpClient.GetStringAsync未被正确 await、或直接调用
File.ReadAllText这类同步文件读取。这些操作会占用线程池线程，导致高并发下线程耗尽、请求排队。
实操建议：
所有外部调用（HTTP、数据库、文件、缓存）必须使用异步版本，并完整 await，避免.Result或
.Wait()ASP.NET Core 默认配置下，
ThreadPool.SetMinThreads(100, 100)这类手动调优无效且危险——.NET 6+ 已自动优化线程池增长策略，强行修改反而干扰调度 检查第三方 SDK 是否提供异步 API；若只有同步接口（如某些旧版 Redis 客户端），考虑升级或封装为
Task.Run（仅限 CPU-bound 场景，I/O-bound 不适用）
public async Task<ActionResult<User>> Get(int id)
{
// ✅ 正确：全程 async/await
var user = await _userRepository.GetByIdAsync(id);
if (user == null) return NotFound();
<pre class='brush:php;toolbar:false;'>var profile = await _httpService.GetProfileAsync(user.ProfileUrl);
return Ok(new { user, profile });}
减少中间件和过滤器中的同步阻塞逻辑
自定义
ActionFilter、
AuthorizationHandler或中间件里执行
HttpContext.Request.Body.Read、
JsonConvert.DeserializeObject等操作，极易成为并发短板。尤其当请求体较大时，同步反序列化会锁住线程。
实操建议：
避免在OnActionExecuting中同步读取
Request.Body；改用
HttpContext.Request.ReadFormAsync()或模型绑定（Model Binding）自动处理 日志记录不要在过滤器中做耗时格式化（如拼接大量字符串或调用外部服务），改用结构化日志（Serilog +
LogContext）并异步写入 身份验证尽量复用
Bearer+ JWT 验证，避免每次请求都查数据库；必要时加内存缓存（
IDistributedCache）存 token 声明
合理配置 Kestrel 和连接管理
Kestrel 是 ASP.NET Core 默认服务器，其默认连接限制和缓冲区设置在高并发场景下可能成为隐性瓶颈。例如未调整
MaxConcurrentConnections或
MaxRequestBodySize，会导致连接被静默拒绝或内存暴涨。
实操建议：
在Program.cs中显式配置 Kestrel：
options.Limits.MaxConcurrentConnections = 1000;（根据服务器核数和内存调整，非越大越好） 禁用不必要的 HTTP/2 特性（如服务器推送）——除非明确需要，否则它会增加连接状态开销 对上传接口单独设限：
options.Limits.MaxRequestBodySize = 10 * 1024 * 1024;，避免大文件请求长期占用连接 确认反向代理（Nginx / Azure Front Door）未设置过低的
keepalive_timeout或连接数限制，否则 Kestrel 调优无效
var builder = WebApplication.CreateBuilder(args);
builder.WebHost.ConfigureKestrel(serverOptions =>
{
serverOptions.Limits.MaxConcurrentConnections = 500;
serverOptions.Limits.MaxRequestBodySize = 5 * 1024 * 1024;
});慎用 Task.Run
和同步上下文切换
看到“CPU 密集型任务”就套
Task.Run是常见误区。它只是把工作扔给线程池，但若大量使用，反而加剧线程竞争，且无法解决 I/O 瓶颈。
实操建议：
仅在真正 CPU-bound 场景下用Task.Run（如图像缩放、加密解密、复杂计算），并确保有明确超时和取消支持 避免在 Controller 中写
Task.Run(() => { /* 同步 DB 查询 */ }).Result——这等于用线程池线程干了本该由异步驱动的事，还丢了上下文
不要在 async void方法中处理请求逻辑（如事件处理器），会导致异常无法被捕获，影响整个请求生命周期
实际压测时，
HttpClient复用、数据库连接池大小、JSON 序列化器配置（如禁用
ReferenceHandler循环引用检测）往往比代码结构更影响吞吐量。这些细节不显眼，但一并发就暴露。
