Laravel API性能优化需从七方面入手：一、避免N+1查询，强制预加载；二、精简返回字段，禁用SELECT *；三、启用游标分页替代offset；四、剥离冗余中间件；五、高频只读数据加缓存；六、大批量场景绕过Eloquent直连查询构建器；七、通过Debugbar/Telescope监控定位瓶颈。
如果您在使用 Laravel 框架开发 API 时发现接口响应缓慢、内存占用高或数据库查询耗时长，则很可能是由于查询方式不当、中间件冗余或数据加载策略不合理所致。以下是针对 Laravel 框架 API 查询性能优化的多种具体方法：
一、避免 N+1 查询，强制预加载关联数据
当遍历模型集合并访问其关联关系（如 $post->user->name）时，Laravel 默认会为每条记录单独执行一次关联查询，导致大量重复 SQL，严重拖慢响应速度。通过预加载可将多次查询合并为一次 JOIN 或子查询。
1、在控制器中使用 with() 显式声明需加载的关联关系，例如：Post::with('author', 'category')->get()
2、对深层嵌套关联启用懒加载保护，添加 protected $touches = ['author'] 到相关模型中防止意外触发
3、若仅需关联字段而无需完整模型实例，改用 selectSub() 或原生 JOIN 查询替代 with()
二、精简返回字段，禁用 SELECT *
默认调用 get() 会拉取整行数据，包含大量未使用的字段，增加序列化开销与网络传输负担。限制字段可显著降低内存峰值与响应体积。
1、使用 select() 明确指定字段列表，例如：User::select('id', 'name', 'email', 'updated_at')->get()
2、在 API Resource 中重写 toArray() 方法，剔除敏感或冗余字段（如 password_hash、remember_token）
3、对大型文本字段（如 content、description）启用条件加载，仅当请求参数含 include_content=1 时才 select
三、启用游标分页替代传统 offset 分页
当数据量超过十万级时，paginate() 的 LIMIT OFFSET 机制会导致 MySQL 扫描大量无用行，越往后翻页越慢。游标分页基于排序字段值跳跃定位，性能恒定且支持断点续传。
1、确保排序字段（如 id 或 created_at）已建立数据库索引
2、在控制器中调用 cursorPaginate() 并传入固定每页数量，例如：$users->cursorPaginate(500)
3、前端需保存并传递上一页返回的 next_cursor 值，不可手动构造或修改游标字符串
四、剥离冗余中间件与 HTTP 栈开销
Laravel 的 apiResource 路由若被错误包裹在 web 中间件组下，将强制启动 session、加载视图服务、校验 CSRF 等与 API 无关的逻辑，显著增加请求延迟。
1、检查 routes/api.php 文件，确认所有路由未附加 ->middleware('web')
2、在 app/Http/Kernel.php 中为 API 路由定义独立中间件组，仅保留 throttle、auth:sanctum 等必要中间件
3、禁用 ShareErrorsFromSession 和 VerifyCsrfToken，二者对无状态 API 完全无效且消耗资源
五、使用缓存层拦截高频只读查询
对于配置类、字典表、地区列表等低频更新但高频访问的数据，每次请求都查库属于典型浪费。合理使用缓存可将响应时间从百毫秒级降至亚毫秒级。
1、采用 Cache::remember() 包裹查询闭包，并设置差异化过期时间，例如：Cache::remember('countries', 3600, fn() => Country::all())
2、对带参数的过滤查询（如按状态筛选用户），将请求参数拼入缓存键，如 'users_status_active'
3、在数据变更时主动清除相关缓存，避免使用 forget() 时遗漏多级键名，推荐使用标签（tags）批量管理
六、绕过 Eloquent 实例化，直连查询构建器
当处理大批量数据导出、后台统计或流式响应时，Eloquent 模型的属性访问器、日期转换、隐藏字段逻辑会带来可观 CPU 与内存开销。直接操作数组可将内存占用控制在 MB 级别。
1、使用 DB::table() 替代模型调用，例如：DB::table('orders')->where('status', 'shipped')->get()
2、对超大数据集启用 chunkById() 分块处理，避免单次查询加载全部结果到内存
3、序列化前调用 toArray() 而非 json_encode() 直接作用于集合，防止自动触发隐式转换
七、监控真实查询行为，定位瓶颈源头
未经观测的优化是盲目的。仅凭经验调整可能忽略真正拖慢接口的慢查询或低效索引。必须借助工具捕获实际执行的 SQL 及其执行计划。
1、在本地环境启用 Laravel Debugbar，查看每个请求的查询次数、总耗时与最慢语句
2、在生产环境部署 Laravel Telescope，配置 watchers 捕获慢查询（如 > 200ms）并记录绑定参数
3、对 Debugbar 或 Telescope 报出的慢查询，使用 EXPLAIN 分析执行计划，确认是否命中索引、是否存在临时表或文件排序
