ASP.NET性能瓶颈常藏在看似无害的细节里：同步IO阻塞线程、未缓存的重复查询、序列化开销过大、中间件堆叠过重。一位后端架构师不会先调优，而是先观测——用Application Insights或OpenTelemetry捕获真实请求路径、GC频率、数据库等待时间与HTTP队列堆积情况。

数据访问是最大突破口。Entity Framework默认加载模式易触发N+1查询，改用AsNoTracking()处理只读场景，配合显式投影（Select）而非全实体加载；批量操作交由EF Core 7+的ExecuteUpdate/ExecuteDelete替代循环SaveChanges；高频读取数据引入MemoryCache，但避免缓存过期策略粗糙——按业务语义分级：用户会话信息设为滑动过期，配置类数据用绝对过期+后台刷新。

异步不等于性能提升，盲目async/await反而增加上下文切换开销。Controller中所有IO操作必须异步（如await _db.Users.FindAsync(id)），但CPU密集任务不应用await Task.Run——这类计算应前置到消息队列或独立工作服务中执行。

JSON序列化是隐藏的“杀手”。System.Text.Json默认配置会反射遍历属性，对深嵌套对象或大数组造成显著延迟。预生成源码序列化器（Source Generator）可消除运行时反射；禁用驼峰命名转换（PropertyNameCaseInsensitive = false）减少字符串处理；必要时对敏感字段启用JsonIgnore，避免序列化无关数据。

中间件顺序决定性能天花板。静态文件中间件必须置于UseRouting之前；自定义日志或认证中间件若含同步IO或复杂逻辑，需拆解为轻量过滤器或委托；跨域（CORS）策略应在开发环境精简，在生产环境严格按需启用，避免预检请求被误放行。

发布前必做三件事：启用IIS动态压缩（gzip/brotli）、关闭ASPNETCORE_ENVIRONMENT开发值、将web.config中httpCompression设为最低阈值128字节；Kestrel则通过WebHostBuilder配置Limits.MaxRequestBodySize与KeepAliveTimeout，防止慢速攻击拖垮连接池。

AI图片，仅供参考

性能不是配置出来的，而是用Production级指标反向驱动的。一次API响应从800ms压至120ms，往往靠的是砍掉一个未索引的WHERE条件，或把Redis缓存粒度从“全用户数据”收缩到“用户权限集合”。架构师真正的武器，是让每个优化决策都有可观测依据，而非凭经验猜错瓶颈。