线上laravel响应慢主因是缓存未稳、查询未压、配置未固化、环境未调优：redis连接未池化、缓存键无前缀、ttl失当、n+1查询、缺失索引、未执行config:cache/route:cache、app_debug开启、opcache未启用、中间件阻塞及队列未异步化。
线上 Laravel 响应慢，通常不是框架本身“不行”，而是几个关键环节没对齐生产要求：缓存没稳住、查询没压住、配置没固化、环境没调优。
缓存配置与使用不当
这是高并发下最常被忽视的性能雷区：
- Redis 连接未池化，导致每请求新建连接，连接数暴涨甚至打满 Redis 服务
- 缓存键无统一前缀（如 prod_v2:），新旧版本缓存混用，逻辑错乱
-
Cache::remember()闭包返回null或抛异常，结果把空值或错误状态缓存下来，后续请求全走“假命中” - TTL 设置严重偏离业务时效性——用户资料页缓存 24 小时，管理员刚改完邮箱，前端一小时都刷不出来
-
config/cache.php和config/database.php中 Redis 连接名不一致，或修改.env后没运行php artisan config:clear，实际连的是默认本地地址
数据库查询低效
ORM 的便利性容易掩盖 N+1 和冗余查询问题：
- 循环中调用关联属性（如
$user->profile->email）触发多次 SQL，100 个用户可能发出 101 条查询 - 未加索引的 where 字段（如 status、created_at）在大数据量下全表扫描
- 使用
get()加载全部数据再 PHP 端过滤，而非用where()下推条件 - 未启用查询日志或慢查询监控，问题长期潜伏
部署配置未优化
本地开发能跑 ≠ 线上能扛压，很多项目漏掉基础固化步骤：
- 未执行
php artisan config:cache，每次请求都重读数十个配置文件 - 未执行
php artisan route:cache，路由匹配靠动态解析，而非预编译数组 -
APP_DEBUG=true仍开启，堆栈、SQL 日志大量写磁盘，拖慢响应 - 未启用 OPcache，PHP 脚本每次请求都重新编译，白白消耗 CPU
- 视图未缓存或频繁重编译（尤其 Blade 中含大量
@include和动态路径）
中间件与任务阻塞主线程
看似轻量的操作，在高并发下会迅速放大延迟：
- 全局中间件中做耗时操作（如远程鉴权、同步日志上报、未加缓存的权限检查）
- 邮件发送、Excel 导出等任务未丢进队列，直接在 HTTP 请求中同步执行
- 队列驱动仍为
sync，QUEUE_CONNECTION=redis未生效，延迟任务完全不触发 - 队列 worker 进程未用 Supervisor 守护，崩溃后无人重启，任务堆积
