Laravel接口性能优化需聚焦SQL定位（Debugbar Queries面板查N+1、慢查询日志分析）、分层缓存（配置/模型/列表差异化策略）、精准异步（仅外部依赖/资源密集/弱一致性场景入队列）及Octane协程适配（连接池、非阻塞I/O、协程化Redis）。
接口性能卡顿，往往不是代码写得不够“炫”，而是几个关键环节没理清：SQL查得重、缓存没用对、异步逻辑还塞在请求里、服务模型仍跑在传统PHP-FPM上。Laravel本身不慢，慢的是没按它的运行机制去设计——尤其当接口要扛住百并发或处理复杂聚合时。
揪出SQL慢在哪：不只是加索引
别急着优化语句，先确认慢点在哪一层：
- 用 Debugbar 的 Queries 面板看实际执行的 SQL、绑定参数、是否触发 N+1（比如循环中调用 $user->posts）
- 开启 MySQL 慢查询日志，重点关注 Rows_examined 远大于 Rows_sent 的语句，说明扫描太多但返回极少
- 对分页场景，避免 OFFSET 大偏移，改用游标分页（WHERE id > ? ORDER BY id LIMIT 20）
- 关联查询用 with() 预加载，但别无脑全预载；用 loadMissing() 或按需懒加载更可控
缓存不是“全加Redis”：分层+过期策略才有效
缓存滥用比不用更危险——数据不一致、击穿、雪崩都源于没分清缓存粒度和生命周期：
- 高频只读数据（如地区字典、系统配置）：用 config:cache + php artisan config:clear 部署时刷新，不走 Redis
- 单条模型数据（如用户资料）：用 Cache::remember('user:123', 3600, fn() => User::find(123))，key带业务标识，TTL设合理值
- 列表/聚合结果（如首页推荐）：用缓存标签（Cache::tags(['home', 'recommend'])->remember(...)），便于批量清除
- 防穿透：空结果也缓存（如 Cache::remember('user:999999', 60, fn() => User::find(999999) ?: null)），避免反复打库
队列不是“为异步而异步”：区分同步阻塞与真正耗时
把所有耗时操作丢进队列，反而可能掩盖设计问题。重点识别三类必须异步的场景：
- 外部依赖型：调第三方 API（短信、支付回调通知）、发邮件、生成 PDF 报表
- 资源密集型：大文件导出、图像压缩、批量数据清洗（用 chunkById + 队列任务分片）
- 非强一致性型：更新统计字段（如文章阅读数）、记录行为日志、推送站内信
- 注意：登录态校验、权限判断、核心事务逻辑不能放队列——它们必须同步完成并反馈给用户
Octane 不是“一键加速”：启动模型与协程适配是关键
Octane 让 Laravel 常驻内存，但默认仍基于同步阻塞 I/O。要真正释放并发能力，得配合改造：
- 数据库连接池需启用（DB_CONNECTION_POOL=true），否则每个请求仍抢同一个 PDO 实例
- 避免在控制器中使用 sleep()、file_get_contents() 等阻塞调用；改用 Swoole 协程版（如 Swoole\Coroutine\Http\Client）
- Redis 客户端换 predis/predis 为 phpredis 并启用 SWOOLE_HOOK_REDIS，才能真正协程化
- 自定义 Artisan 命令若需长时运行，加 #[AsCommand] 注解使其支持协程调度
