php artisan route:cache是生产环境第一优先级优化，它将路由编译为静态数组写入bootstrap/cache/routes-v7.php，跳过动态解析与正则匹配，使路由匹配变为纯数组遍历，性能提升3–5倍；但不支持闭包路由及运行时动态注册。
生产环境不跑 php artisan route:cache，请求生命周期就白优化了一半。 这不是锦上添花，而是基础门槛——Laravel 的路由解析在未缓存时是纯 PHP 文件加载 + 正则匹配，千条路由下每次请求都要重解析，CPU 耗在 RouteCollection::match() 里，和业务逻辑无关。
为什么 route:cache 是第一优先级
未缓存时，Laravel 每次请求都要：读取 routes/web.php 和 routes/api.php、执行其中的 Route::get() 等调用、构建完整 RouteCollection 对象、再逐条正则匹配。这个过程无法复用，且闭包路由（function () { ... }）还会导致 APCu 或 OPcache 无法有效缓存。
-
php artisan route:cache会把所有注册的路由编译成一个静态数组，写入bootstrap/cache/routes-v7.php（版本号随 Laravel 升级变化） - 后续请求直接 require 这个文件，跳过全部动态注册逻辑，匹配走纯数组遍历 + 字符串比对，性能提升常达 3–5 倍
- 它只影响 HTTP 请求，不影响
php artisan命令行调用 - 注意：不能缓存含闭包的路由；若用了
Route::macro()或运行时动态注册，缓存会失败并报错Unable to prepare route [...] for serialization
config:cache 和 view:cache 的实际影响边界
这两个命令效果真实，但收益场景有限，容易误用。
-
php artisan config:cache合并config/下所有文件为单个 PHP 数组，避免每次请求都require十几个配置文件。但它会覆盖.env中的动态值（如DB_HOST），所以必须确保所有环境变量已通过env()正确注入到配置中，否则上线后数据库连不上 -
php artisan view:cache编译 Blade 模板为原生 PHP，减少运行时解析开销。但它只对未启用 OPcache 的环境有意义；现代 PHP 通常已开启 OPcache，此时该命令收益极小，甚至因模板变更后忘记清缓存导致页面不更新 - 二者都不支持开发环境热更新，必须配合部署流程使用，比如 CI/CD 流水线中最后一步执行，而非本地
php serve前手动跑
中间件栈顺序不当，会让优化全白费
即使路由和配置都缓存了，一个写错位置的中间件仍能拖垮整个请求链。Laravel 的 $middleware（全局）、$middlewareGroups（web/api 分组）、路由级中间件，执行顺序严格嵌套，错误放置等于给高速路修减速带。
- 认证类中间件（如
auth、throttle）必须放在路由匹配之后才合理；若塞进最外层$middleware，连 favicon.ico 都要走一遍 session 启动和数据库查询 - 日志中间件（如自定义请求记录）别放太前——它依赖
$request->fullUrl()等方法，而这些方法在某些早期中间件里可能尚未就绪 - 所有中间件里的
handle()方法必须有明确的return $next($request)，漏掉或写成$next($request); return null;会导致后续中间件和控制器完全不执行，静默失败
服务提供者里做重操作，等于在每个请求头上钉钉子
AppServiceProvider::boot() 是常见陷阱区。很多开发者习惯在这里初始化 Redis 客户端、预加载字典表、甚至调用外部 API，以为“只执行一次”。但 boot() 在每次请求都会执行——只要该服务提供者被加载，而默认几乎所有服务提供者都在 config/app.php 的 providers 列表里。
- 真正“一次”的地方是
register()，但这里只能绑定服务，不能执行耗时操作（因为容器还没完全构建好） - 需要预热的数据，应改用 Artisan 命令 + 定时任务（
scheduler）写入 Redis 或本地缓存，控制器里直接读 - 第三方 SDK 初始化（如支付宝、微信支付）务必延迟到首次使用时单例构造，而不是在
boot()里 new 出来 - 检查是否误将
Event::listen()放在boot()外部——这会导致每次请求重复监听，内存泄漏风险高
真正的提速不在炫技式的异步或协程改造，而在掐准三个不可绕过的执行点：路由是否真缓存、配置是否没被 .env 反向污染、中间件是否在它该在的位置。其他所有优化，都建立在这三根柱子不歪的前提上。
