路由缓存编译routes/web.php和api.php中静态路由为PHP数组文件以加速匹配，配置缓存合并config/与.env配置为单文件以跳过运行时加载；二者生效阶段、作用对象及部署顺序均不同。
路由缓存和配置缓存都是 Laravel 生产环境性能优化的关键环节，但它们作用的对象、触发时机、生效范围完全不同。理解差异才能避免部署踩坑——比如 config:cache 之后改了 .env 却没生效，或 route:cache 后新增路由 404。
路由缓存：只加速「匹配」，不改变「定义来源」
route:cache 把 routes/web.php 和 routes/api.php 中顶层静态声明的 Route::get()、Route::post() 等语句 编译成一个 PHP 数组文件（如 bootstrap/cache/routes-v9.php），后续所有 HTTP 请求都绕过原始路由文件，直接查这个数组做路径匹配。
- 它不执行任何闭包、
Route::fallback()、if条件包裹的路由、中间件里动态注册的路由 - 缓存后，修改 routes/*.php 文件完全无效，必须重新
route:clear && route:cache - Laravel 11+ 默认生成带版本号的文件（如
routes-v11.php），避免旧缓存残留干扰 - CLI 命令（如队列、schedule）默认不自动使用路由缓存，需手动调用
$this->app->useCachedRoutes()
配置缓存：固化「运行时合并结果」，跳过 config/ 文件扫描
config:cache 将 所有 config/*.php 文件 + .env 中的键值 + 服务提供者中通过 $this->mergeConfigFrom() 注入的配置 合并为单个 bootstrap/cache/config.php，应用启动时直接 require 这个文件，不再逐个加载和 merge。
- 它不缓存运行时动态计算的配置（如
config(['app.name' => request()->getHost()])） - 一旦生成，
.env修改将被忽略，除非重新运行config:cache - 必须在
composer install --no-dev之后执行，否则开发专用配置（如 debugbar）可能意外进入生产缓存 - 某些包（如 Laravel Horizon）依赖未缓存的配置项，需确认其文档是否兼容 config:cache
生效机制关键差异对比
两者都依赖「PHP 文件写入 + 自动 require」，但介入阶段和影响面不同：
-
路由缓存 在请求进入路由器（Router）前生效，影响的是
Illuminate/Routing/Router实例的$routes属性来源 -
配置缓存 在应用实例化早期（Application 构造后、Providers 注册前）生效，影响的是整个框架对
config()函数的响应 - 路由缓存可单独启用，不影响 config 缓存；但若启用了 config 缓存而没启 route 缓存，路由解析仍会慢——因为 RouteServiceProvider 仍要重新加载全部路由文件
- 两者都要求
bootstrap/cache/目录对 Web 服务器用户（如 www-data）可读，且不能可写（防意外覆盖）
部署顺序不能错
标准上线流程中，两者的执行顺序有强依赖：
- 先
composer install --no-dev（确保无 dev-only 包干扰） - 再
php artisan config:cache（让后续命令读取到正确配置） - 然后
php artisan route:cache（此时它会读取已缓存的 config，例如中间件名、控制器命名空间等） - 最后才重启 PHP-FPM 或重载 Web 服务器
反序操作会导致 route:cache 读到错误的中间件别名或找不到控制器类，生成的缓存文件直接失效。
