线上接口响应慢用户抱怨老板催命。排查半天发现不是单一原因而是多个小问题叠加。我总结了8个最常见的性能陷阱看看你中了几个。1. N1查询ORM框架的懒加载是罪魁祸首。查订单列表每个订单再查用户信息一次请求打出几百条SQL。数据库连接被占满响应时间飙升。解决用JOIN或批量查询MyBatis的BatchSize、JPA的EntityGraph都能合并查询。2. 索引缺失或失效查询字段没索引或者对字段用了函数、发生隐式类型转换导致全表扫描。明明加了索引WHERE DATE(create_time) 2024-01-01却让索引失效。解决用EXPLAIN分析执行计划避免在索引列上做运算注意字段类型匹配。3. 同步调用外部接口在请求链路里同步调用第三方API对方慢你就慢。更糟的是没有超时控制线程一直阻塞。解决异步化、设置合理超时、加熔断降级。CompletableFuture或响应式编程能把串行变并行。4. 返回过多数据接口一次性返回几千条记录序列化和网络传输都慢。前端可能只需要前20条。解决强制分页只返回必要字段用DTO代替实体类避免返回大字段如文本、图片base64。5. 缓存使用不当没缓存或者缓存击穿、雪崩。热点key过期瞬间所有请求打到数据库。解决合理设置过期时间加互斥锁或逻辑过期多级缓存本地Redis热点数据永不过期。6. 连接池配置不当数据库连接池太小请求排队等连接太大数据库扛不住。HTTP客户端没复用连接每次新建TCP。解决根据QPS和RT计算合理池大小公式是连接数 QPS × RT。用HttpClient连接池别用new URL().openConnection()。7. 低效序列化与日志JSON序列化大对象循环里打日志日志同步写磁盘。解决按需序列化用异步日志Logback AsyncAppender避免在循环中打日志生产环境关闭DEBUG级别。8. 锁竞争与线程池配置全局锁导致串行化synchronized方法里做耗时操作。线程池队列无限大导致任务堆积核心数设成CPU核数却跑IO密集任务。解决减小锁粒度用无锁结构CAS、LongAdderIO密集任务线程数设为CPU核数 × (1 等待时间/计算时间)。总结接口慢往往是多个因素叠加。不要凭感觉优化先用Arthas、SkyWalking、Prometheus定位瓶颈再逐个击破。记住没有测量就没有优化。先解决最大的瓶颈再验证效果避免过度优化引入新问题。