接口响应慢，大概是后端开发时最常撞上的性能问题：页面一直转圈、App 卡住、请求直接超时报错，用户体验立刻往下掉。碰到这种事别急着加机器，先按「定位瓶颈 → 对症优化」的思路走，往往花不了多少成本就能把问题解决掉。
第一步：先定位，别瞎猜
优化的前提是你得知道慢在哪。建议顺着链路一段段查：
- 看总耗时分布：用
curl -w "%{time_total}"或浏览器的 Network 面板，先分清是网络慢还是服务端慢。 - 加链路日志：在接口入口、数据库调用、外部请求前后都打上时间戳，或者接 SkyWalking、Zipkin 这类 APM 工具，把最慢的那段揪出来。
- 看数据库慢查询：MySQL 打开
slow_query_log，把超过 1 秒的 SQL 全捞出来。
数据库层：最常出问题的地方
- 加索引：用
EXPLAIN看执行计划，出现全表扫描（type=ALL）就该给查询条件字段建索引了。 - 避免 N+1 查询：在循环里发 SQL 是大忌，改成批量查询或一次 JOIN 取回。
- 只查需要的字段：别用
SELECT *，大字段（TEXT/BLOB）按需加载。 - 分页优化：深分页用「上一页最大 ID」做游标，别写
LIMIT 100000,20。
应用层：缓存与异步
- 加缓存：读多写少的数据放 Redis，热点数据再加一层本地缓存，命中之后响应能从几百毫秒掉到几毫秒。
- 异步化：发短信、写日志、发通知这类非核心逻辑丢进消息队列（如 RabbitMQ、Kafka），接口只做必须同步的事。
- 并行调用：要调多个下游接口时，用并发请求代替串行等待，总耗时取最长的那个而不是全部相加。
- 连接池：数据库、HTTP 客户端都要用连接池，别每次请求都重建连接。
网络与架构层
- 压缩响应：开 Gzip/Brotli，精简返回字段，别把整张表往前端甩。
- 用 CDN 和就近部署：静态资源走 CDN，跨地域访问考虑多机房部署。
- 限流与降级：高峰期保住核心接口，别让一个慢接口把整个服务拖垮。
小结
接口优化说白了就一句：先测量、再定位、后优化，优先动数据库和缓存，最后才考虑加机器。每改一处都记得复测对比数据，别凭手感调。
你在项目里遇到过哪些棘手的接口性能问题？欢迎到 fenij.com 评论区留言，聊聊你的排查经历和优化技巧。
