先确认缓存日志是否开启并检查真实key与连接状态：需配置cache日志通道、设level为debug/info，验证key是否被哈希、直连Redis测试认证及DB，检查request_cache的缓存头与key稳定性。
缓存命中失效？先确认日志里有没有写“cache miss”
ThinkPHP 默认不会把缓存读写行为记进日志，所以你看到 runtime/log/ 里没相关记录，不等于缓存没动——它可能根本没被触发，或者静默失败了。
必须手动打开缓存调试日志：在 config/log.php 的 'channels' 中为缓存通道加一条配置，比如：
'cache' => [
'type' => 'File',
'path' => runtime_path('log/cache/'),
],
再在 config/cache.php 里指定日志通道：
'driver' => 'redis', 'logger' => 'cache', // ← 关键！让缓存操作走这个通道
- 不配
logger，哪怕缓存驱动是 redis，也不会打任何日志 - 日志路径要确保
runtime/log/cache/目录存在且可写，否则日志直接丢弃 - 日志级别默认只记
warning和error，想看到hit/miss，得把'level'设为['debug', 'info']
Cache::get() 返回 null，但你以为是没命中，其实是 key 被悄悄改了
ThinkPHP（尤其 TP6+）对缓存 key 会自动哈希或截断。你传 'user:123:profile'，底层可能存成 6b86b273ff34fce19d6b804eff5a3f5747ada4eaa22f1d49c01e52ddb7875b4b，导致你用原 key 查不到，误判为“失效”。
立即学习“PHP免费学习笔记（深入）”；
- 用
Cache::has('user:123:profile')返回false，不代表真没存；先查Cache::get('user:123:profile')再 dump 结果，看是不是null或false - 开启 debug 日志后，在
runtime/log/cache/里搜get和set，对比实际使用的 key 是什么 - 若需绕过 key 处理，可用
Cache::store('redis')->get('user:123:profile')，跳过框架默认封装
Redis 驱动连上了，但缓存还是不生效——检查连接是否真通、密码是否对
ThinkPHP 报错静默，CACHE_DRIVER=redis 配置正确 ≠ 缓存真的在用 Redis。常见假连状态：能 ping 通 IP 端口，但认证失败、DB 选错、甚至连的是本地空实例。
- 执行命令
php -r "print_r((new Redis())->connect('127.0.0.1', 6379) && (new Redis())->auth('your_pass'));"，确认 PHP 层直连成功 - 检查
config/cache.php中'password'和'database'是否与redis.conf一致；TP 默认用 DB 0，如果 Redis 设置了requirepass却没填密码，所有写入都失败 - 用
redis-cli -a your_pass进去后执行KEYS cache_*，看有没有数据；没有，说明写入压根没成功，不是命中问题，是存储失败
用了 request_cache，但页面每次刷新都重算——漏了缓存限制器
TP5.1 的 request_cache 依赖 HTTP 缓存头控制，如果没设 session_cache_limiter，浏览器或 CDN 可能拒绝缓存响应，导致服务端反复执行逻辑。
- 在
public/index.php最开头加：session_cache_limiter('public');（注意必须在require base.php前） - 同时确认
config/app.php中'request_cache_key'是否稳定——比如含时间戳、随机数、用户 session ID，都会让 key 变化，必然 miss - 开启后用浏览器 DevTools → Network → 查看响应头是否有
Cache-Control: public, max-age=3600；没有，说明 request_cache 没真正启用
缓存失效最常卡在“以为配置好了”，其实连基础连通性或日志开关都没打开。盯住日志输出和真实 Redis 数据，比猜逻辑更可靠。
