Laravel 5.5 性能问题主因是未正确启用 config:cache 和 route:cache：config:cache 要求所有配置用 env() 显式读取，否则缓存后失效；route:cache 仅支持控制器路由，闭包路由会报错；with() 需精简字段防 N+1；大数据量分页应改用 cursorPaginate() 或 chunkById()。
不是 Laravel 5.5 本身慢，而是没开 config:cache 和 route:cache，或者开了但用法错了——这俩命令能直接砍掉每次请求 5–15ms 的启动开销，但错配会导致功能失效。
config:cache 必须开，但 env() 必须显式调用
运行 php artisan config:cache 后，Laravel 不再读取 .env 文件，只从生成的 bootstrap/cache/config.php 中取值。这意味着：如果 config/app.php 里写的是 'debug' => true，而不是 'debug' => env('APP_DEBUG', false)，那 .env 里的 APP_DEBUG=true 就完全失效。
- 所有配置文件中涉及环境变量的地方，必须用
env()显式声明，否则缓存后值固定为默认值 -
APP_URL、DB_HOST、REDIS_HOST等关键配置漏掉env()会导致数据库连不上、缓存写不进 Redis - 改了
config/下任意文件，必须先php artisan config:clear再php artisan config:cache，否则变更不生效
route:cache 只支持控制器路由，闭包路由会直接报错
php artisan route:cache 会把全部路由注册逻辑固化成 PHP 数组，跳过每次解析 routes/web.php。但它不兼容匿名函数写法：
-
Route::get('/', function () { return view('welcome'); });→ 运行route:cache时直接抛出LogicException: Unable to cache routes -
Route::get('/posts', [PostController::class, 'index']);和Route::apiResource('users', UserController::class)是安全的 - 用了
Route::group套闭包、或在路由里调用app()/resolve()等容器方法，也会失败
with() 预加载字段不精简，等于白优化
with() 是防 N+1 的核心手段，但拉回整张关联表（比如 User::with('posts')->get()）反而拖慢响应，尤其当 posts 表有 content 字段（几 KB 文本）时。
- 只取必要字段：
Post::with(['user:id,name,email'])->get()，避免带password_hash或大文本字段 - 别在 Blade 循环里写
{{ $post->user->name }}却没预加载——Debugbar 的 “Queries” 面板出现一串重复 SQL 就是典型 N+1 - 条件性加载用
$post->loadMissing('author')，比无脑with()更省资源
分页超 10 万条数据时，paginate() 是性能杀手
paginate() 底层靠 LIMIT OFFSET，MySQL 要扫描前面所有行。10 万条数据翻到第 100 页时，OFFSET 99999 会让查询变卡；高并发下还可能锁表。
- 真实数据量 > 10 万，优先用
cursorPaginate()，要求排序字段（如id或created_at）已建索引 - 前端必须传真实的游标值（如
?cursor=12345），不能手动拼接或伪造 - 批量处理用
chunkById(1000)，它基于主键范围查询（WHERE id > ? AND id ），比 <code>chunk()稳定得多——但只适用于整型自增主键
最常被忽略的点：开了 config:cache 却没关 APP_DEBUG=true，或开了 route:cache 却混用闭包路由——这两类错误不会报错，但会让缓存形同虚设，性能毫无改善。
