route:cache、中间件分组、OPcache、event异步化是高并发下Laravel性能四大关键优化点：未缓存路由千级匹配耗10–15ms，缓存后提升3–5倍；中间件需按请求类型分组避免无效执行；OPcache必须启用且禁用时间戳验证；事件监听器须实现ShouldQueue接口方可异步。
高并发下 Laravel 请求生命周期不优化，再好的业务逻辑也扛不住——核心瓶颈往往不在数据库或代码，而在框架启动、路由解析、中间件加载这些“固定开销”上。直接改代码没用，得从请求入口开始砍掉冗余路径。
为什么 route:cache 是第一道硬门槛
没跑 php artisan route:cache，所有后续优化都打七折。未缓存时，每次请求都要重载 routes/web.php、执行 Route::get() 等动态注册、构建 RouteCollection、逐条正则匹配；千级路由下，RouteCollection::match() 就吃掉 10–15ms CPU。缓存后变成纯数组遍历 + 字符串比对，实测提升 3–5 倍。
- 必须部署后立即执行，且只对 HTTP 请求生效，不影响 Artisan 命令
- 不支持闭包路由（
Route::get('/', function () { })）和运行时动态注册（如Route::macro()），否则缓存失败报Unable to prepare route [] for serialization - 缓存文件写入
bootstrap/cache/routes-v7.php（Laravel 版本号不同会变），记得加进 .gitignore
中间件栈顺序错一位，性能就归零
全局中间件（$middleware）放在最外层，等于让 favicon.ico、/robots.txt、健康检查接口也走一遍 session 启动、CSRF 验证、甚至 auth 认证——这是高频压垮 FPM 的隐形杀手。
- 把
StartSession、EncryptCookies这类重量级中间件移到$middlewareGroups['web']里，确保只对真实页面请求生效 -
throttle:api必须放在路由匹配之后，否则连 OPTIONS 预检请求都被限流，CORS 直接失败 - 自定义中间件若含 DB 查询或 Redis 调用，务必加
return $next($request)短路逻辑，避免无意义穿透
PHP-FPM 和 OPcache 不调，框架层再快也没用
Laravel 启动慢，80% 是 PHP 底层在拖后腿：OPcache 关着、FPM 子进程配爆内存、xdebug 悄悄开着——这些配置错误比代码问题更致命。
Laravel Cloud（cloud.laravel.com）。此技能用于处理所有 Laravel Cloud 请求，包括搜索和读取数据。只要任务涉及 Laravel Cloud，即使用此技能。
-
opcache.enable=1必须开，顺带设opcache.validate_timestamps=0；否则每次请求都重编译全部框架类，CPU 瞬间拉满 -
pm.max_children别照抄“4 核配 120”，Laravel 进程平均占 50MB；8GB 服务器建议设为60，留足系统和其他服务空间 -
xdebug.mode=off或干脆卸载 xdebug 扩展；只要加载着，单请求就多耗 80–200ms，QPS 直接腰斩 - 确认
post_max_size和upload_max_filesize匹配（如后者设 20M，前者至少 22M），否则大文件上传时$_FILES为空且无提示
event() 同步调用是埋得最深的坑
event(new OrderShipped($order)) 默认同步执行所有监听器，哪怕监听器里只有一行邮件发送，也会卡住当前请求。这不是 Laravel bug，是设计使然——它不会自动帮你投队列。
- 监听器类必须显式实现
ShouldQueue接口，否则永远同步 - 别在监听器
handle()里手动dispatch(new SendEmailJob())，冗余且增加序列化风险 - 高频事件（如点击埋点）别走 Laravel 队列，直接写 Kafka 或本地日志，由后台服务批量消费
-
ShouldBroadcast接口必须配独立广播队列：BROADCAST_QUEUE=redis-broadcast，并单独启监听：php artisan queue:work --queue=redis-broadcast
真正卡住高并发的，从来不是某段 SQL 或某个模型方法，而是那些你以为“框架自己会处理好”的启动环节。route:cache、中间件分组、OPcache、event 异步化——这四件事漏掉任何一个，流量一上来，问题就不是慢，而是不可用。
