核心业务接口优化需遵循“监控→定位→修改→对比→固化”闭环，重点聚焦数据库（占慢因60%+）、缓存分级、异步剥离、传输减法四大方向，目标是99%请求≤100ms且保障正确性。
核心业务接口的响应时间直接影响用户留存、转化率和系统稳定性，优化不能靠猜，得从真实瓶颈入手。重点不是“堆技巧”，而是快速定位、精准干预、验证闭环。
一、先用工具把慢点揪出来
不测量就优化，等于蒙眼修车。生产环境推荐用 Arthas trace 或 SkyWalking 接入，本地开发可用 Spring Boot Actuator + Micrometer 配合 Prometheus 查看各段耗时分布。重点关注：
- 数据库查询（JDBC PreparedStatement 执行时间）
- 远程调用（Feign/Ribbon/OkHttp 的 connect/read 耗时）
- 序列化与反序列化（Jackson 处理 JSON 的时间占比）
- 主线程中隐式阻塞（如未配置超时的 Redis get、同步日志写入）
二、数据库是最大突破口（占慢因60%+）
多数核心接口慢，根源在 SQL。别只加索引，要结合业务场景动刀：
- 把循环内查库改成批量 in 查询（如原逻辑 for (id: ids) { select * from user where id = ? } → 改为 select * from user where id in (?, ?, ?)）
- 关联查询超过3张表时，评估是否拆成 2 次查询 + 应用层组装，避免执行计划退化
- 分页必须用 cursor 分页或延迟关联，禁用 OFFSET，尤其数据量过百万后
- 高频读字段（如商品状态、用户等级）单独建覆盖索引，避免回表
三、缓存要用对地方，不是所有数据都适合缓
核心业务讲究强一致性或最终一致性，缓存策略得分级：
- 读多写少、容忍秒级延迟的数据（如地区字典、活动开关）→ Redis + 设置合理 TTL
- 写频繁但读集中（如用户最近订单）→ Caffeine 本地缓存 + 主动失效（更新 DB 后清除本地缓存）
- 接口幂等且前端可控制（如配置类接口）→ 加 Cache-Control: public, max-age=60，由浏览器或 CDN 缓存
- 坚决不用缓存的：实时交易状态、库存扣减结果、风控决策结果
四、非核心逻辑必须剥离主线程
用户不需要等日志落盘、消息通知、埋点上报才看到页面。Spring 中最稳妥方式是：
- 用 @Async 标记方法，但必须自定义线程池（禁用默认 SimpleAsyncTaskExecutor）
- 高可靠场景（如支付成功后发券）→ 投递到 RocketMQ/Kafka，由消费者异步处理
- 内部服务间调用耗时 >100ms 的，考虑降级兜底（返回缓存值或默认值），并记录告警
五、传输和序列化环节做减法
再快的后端，传 2MB JSON 给前端也白搭：
- 用 DTO 显式声明返回字段，禁止直接返回 Entity 或 Map
- 启用 GZIP（server.compression.enabled=true），实测文本类响应体压缩率常达 70%+
- 内部微服务间调用可换 Protobuf 或 Avro，比 JSON 解析快 3–5 倍
- 列表接口默认限制 size=20，带 total 字段；真需要全量导出走异步任务 + 下载链接
优化不是一次动作，而是一套闭环：监控 → 定位 → 修改 → 对比 → 固化。每次上线前跑一次压测（JMeter 或 wrk），看 P95 RT 是否达标，再观察错误率和 GC 情况。核心业务接口的目标很明确：99% 请求 ≤ 100ms，且不以牺牲正确性为代价。
