未优化的 Laravel 响应时间为 80–150ms，优化后可降至 20–40ms；瓶颈主要在服务容器启动和自动加载，而非 Eloquent；启用路由与配置缓存、禁用调试、精简服务提供者等措施可显著提升性能。
Laravel 默认配置下响应速度偏慢，但可优化到接近原生 PHP 水平
直接说结论：未优化的 Laravel 应用在简单接口（如返回 JSON）上，典型响应时间在 80–150ms（Nginx + PHP-FPM + MySQL），比原生 PHP 或 Slim/Lumen 高出 2–4 倍；但通过合理配置和缓存策略，能压到 20–40ms，与 CodeIgniter、ThinkPHP 5.1+ 接近，仍略慢于 Gin（Go）或 FastAPI（Python），但差距已不构成瓶颈。
关键性能瓶颈在服务容器和自动加载，不是 ORM
很多人归因于 Eloquent，实际压测表明：Eloquent::find() 单条查询耗时占比不足 15%；真正拖慢的是框架启动阶段——每次请求都要解析 config/、注册上百个服务提供者、执行 Container::resolve()、触发大量 class_exists() 和反射操作。Laravel 的自动加载器（composer/autoload_classmap.php）在开发模式下默认不启用 classmap，导致频繁文件 I/O。
- 开发环境务必运行
composer dump-autoload --optimize --classmap-authoritative - 禁用调试模式：
APP_DEBUG=false（否则会收集大量日志和异常上下文） - 移除未使用的服务提供者（如
App\Providers\EventServiceProvider若没用事件，直接删掉） - 避免在
boot()中做阻塞操作（如调用外部 API、读大文件）
缓存路由和配置后，TPS 可提升 3 倍以上
Laravel 的 php artisan route:cache 和 config:cache 不是“锦上添花”，而是生产环境必选项。未缓存时，每次请求都需重新解析全部 routes/web.php 和所有 config/*.php 文件；缓存后，这些变成单次数组查找，耗时从 ~12ms 降到
php artisan config:cache php artisan route:cache php artisan view:cache
注意：route:cache 不支持闭包路由（Route::get('/', function () { ... })），必须改用控制器；view:cache 要求 Blade 模板中不能有动态路径（如 @include($partial)）。
Redis + OPcache 是性价比最高的提速组合
OPcache 开启后，PHP 字节码无需重复编译，artisan serve 下效果不明显，但在 FPM 模式下可降低 CPU 占用 30%+；Redis 替代文件缓存（CACHE_DRIVER=redis）后，Cache::get() 延迟从 ~5ms（file）降到 ~0.3ms（本地 Redis），对高频配置、权限、会话读取帮助极大。
- 确认 OPcache 已启用：
opcache.enable=1且opcache.revalidate_freq=0（生产环境禁用检查） - 避免用
Cache::rememberForever()存大量数据——Redis 内存暴涨且无淘汰策略 - Session 改用 redis 驱动：
SESSION_DRIVER=redis，比 file 或 database 快一个数量级
真实项目中，去掉调试、缓存配置/路由、启用 OPcache 和 Redis 后，相同硬件下 QPS 从 120 跳到 400+，而换框架（比如切到 Lumen）带来的提升通常不到 20%，远不如调优来得实在。
