中间件中直接修改response对象不生效，因laravel中间件链单向执行，需在handle开头读缓存并直接返回，$next后写缓存，且只对200/get等安全场景操作。
中间件里直接改 Response 对象不生效？
因为 Laravel 的中间件链是单向的，handle 方法返回的 Response 会被后续中间件继续处理，但如果你在中间件里手动调用 response()->cache() 或写头信息，框架默认不会拦截后续逻辑——响应可能被后面中间件（比如加密、CSP 头）覆盖，或者根本没走到缓存写入那步。
正确做法是：在中间件中判断是否命中缓存，若命中就直接 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 数据。
