thinkphp的checkrequestcache中间件命中缓存时直接返回响应，彻底跳过后续中间件、控制器及模板渲染；仅对get请求生效，缓存key含完整url，需正确注册顺序并确保redis驱动真实连通。
中间件缓存会跳过后续中间件和控制器逻辑
ThinkPHP 的 CheckRequestCache 中间件一旦命中缓存，就会直接返回响应，不再执行后续中间件、控制器方法、甚至模板渲染。这不是“影响执行”，而是彻底终止请求生命周期——它比 return 还干净。
- 缓存命中时，
handle()内部调用$response = $this->getCacheResponse($request)后直接return $response，后续所有中间件（包括你自定义的）和控制器都不会运行 - 常见误判：你在中间件里加了日志或调试代码没输出，不是“没执行”，是根本没走到那一步
- 该中间件默认只对 GET 请求生效；POST/PUT/DELETE 等方法即使配置了 cache 也不会被拦截
- 缓存 key 默认包含完整 URL（含 query string），
?id=1和?id=2是两个独立缓存项
缓存中间件位置不对会导致失效或冲突
中间件注册顺序决定执行时机，CheckRequestCache 必须放在能捕获“最终响应”的位置，否则可能取不到有效响应体，或被其他中间件覆盖。
- 必须置于
ResponseTrace之后——否则拿不到已包装的响应对象 - 必须置于
SessionInit或LoadLangPack之前——否则语言包加载、会话初始化等前置逻辑会被跳过，导致多语言失效、用户未登录却显示欢迎页等问题 - 不能放在
AllowCrossDomain之后——否则缓存响应不带 CORS 头，前端跨域请求失败 - 全局注册时，建议写在
app/middleware.php数组靠前但避开最开头的位置，例如：[think\middleware\ResponseTrace::class,think\middleware\CheckRequestCache::class, ...]
缓存内容被“固化”后改配置也不生效
请求缓存生成的是完整的 HTTP 响应（含状态码、头、正文），如果缓存内容里混入了动态数据（比如硬编码的用户昵称、时间戳），哪怕你改了控制器或模板，只要缓存没过期，用户看到的永远是旧快照。
- 典型现象：修改了
lang('welcome')对应的语言包，但页面仍显示旧翻译——因为缓存响应里已经把"欢迎"字符串写死了 - 解决方式不是调
Cache::clear()，而是删掉runtime/cache/下对应 URL 的缓存文件，或临时关闭request_cache - 开发阶段建议在
config/app.php中设'request_cache' => false，避免调试时反复清缓存 - 若需区分用户态缓存（如登录/游客不同内容），必须用闭包函数动态生成 cache key，例如
cache(function ($request) { return 'user_' . session('uid') . '_' . $request->url(); })
Redis 缓存驱动配置漏项会静默降级为 file
即使你在路由里写了 ->cache(3600)，只要 config/cache.php 中 stores['redis'] 缺少 host、port、database 或 timeout 任一参数，TP8 就会自动 fallback 到 file 驱动，且不报错、不警告。
- 验证是否真走 Redis：进
php think tinker，执行(new \think\cache\driver\Redis(config('cache.stores.redis')))->handler()->ping()，返回+PONG才算通 -
Cache::set('x', 'y')返回true不代表成功写入 Redis——它只表示“尝试写入成功”，实际可能落在 file 目录里 - 检查
runtime/cache/目录下是否有大量 PHP 文件生成，有则说明 Redis 没生效 - 别依赖
.env里的REDIS_HOST，TP8 不读这些变量，所有参数必须显式写进config/cache.php
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
