如何实现Laravel中间件缓存响应的机制？

本文共计1012个文字，预计阅读时间需要5分钟。

由于 Laravel 的中间件链是单向的，`handle` 方法返回的 `Response` 对象会被后续中间件连续处理。但如果在中间件中手动调用 `response()` 方法，则会跳过后续中间件的执行。

正确做法是：在中间件中判断是否命中缓存，若命中就直接 return 缓存的 Response；否则放行，再在响应返回前通过 ->withHeaders() 或 ->setCache() 注入缓存策略。别试图“修改”已存在的响应对象。

• 缓存读取必须在 handle 开头做，用 Cache::get($key) 拿序列化的 Response
• 写入缓存必须在 $next($request) 之后，且只对 200 状态、GET 请求等安全场景操作
• 注意 Response 序列化时会丢失部分运行时状态（如回调、资源句柄），只缓存可序列化字段（内容、状态码、头）

Response::setCache() 和手动设 Cache-Control 头的区别？

Response::setCache() 是 Laravel 封装的快捷方法，它会同时设置 Cache-Control、Expires、Last-Modified 等多个头，并自动处理 ETag 计算（如果启用）。而手动 header('Cache-Control: public, max-age=3600') 只影响客户端和中间代理，服务端缓存还得自己另搞。

• setCache(['public' => true, 'max_age' => 3600]) 适合控制浏览器/CDN 缓存行为
• 服务端响应缓存（即把整个 Response 存 Redis）必须单独实现，和 setCache() 无关
• 如果用了 setCache() 却没配服务端缓存，用户可能反复请求后端——只是浏览器本地没发请求而已

缓存键怎么设计才不容易冲突或爆炸？

键名不能只依赖 $request->url()，得包含影响响应内容的所有变量：查询参数顺序、Accept 头、登录态（如果是 auth 中间件后置）、甚至语言 locale。否则 /posts?sort=desc 和 /posts?sort=asc 可能共用一个缓存，或者带 JWT 的请求被未登录用户命中。

• 推荐组合：md5($request->fullUrl() . $request->header('Accept') . optional(auth()->user())->id)
• 避免用 $request->all()，它包含 _token、_method 等 CSRF 相关字段，会导致缓存键冗余且不稳定
• Redis 键建议加前缀如 resp:，方便批量清理：redis-cli --scan --pattern "resp:*" | xargs redis-cli del

为什么有些响应缓存了但下次还是走 PHP？

常见原因是中间件注册顺序错了。Laravel 的中间件执行顺序是从外到内（Kernel.php 中数组靠前的先执行），而缓存中间件必须比「验证」「权限」「日志」等更早触发——否则请求还没进缓存层就被拒绝或记录了。

• 确保缓存中间件放在 $middlewareGroups['web'] 最前面，或在路由定义里显式前置：->middleware(['cache.response', 'auth'])
• 检查是否在控制器里调用了 abort(403) 或 redirect()，这些会跳过中间件的 return $next($request) 后续逻辑，导致缓存写入失效
• Session 启用时，默认会加 Vary: Cookie 头，导致每个用户缓存独立——这不是 bug，是预期行为；如需共享缓存，得手动覆盖 Vary 头

缓存中间件真正难的不是写几行代码，而是想清楚「哪些请求值得缓存」「缓存多长」「谁有权击穿它」——这三个问题没理清，代码越完善，线上越容易出不可见的 stale 数据。