缓存没生效需先确认APP_DEBUG=false且缓存驱动正确启用；检查Redis连接、文件路径权限、预热请求、缓存命中率及日志，避免N+1和标签滥用。
缓存没生效？先确认 APP_DEBUG 和缓存驱动是否真启用
压测时发现响应时间没变化，大概率是缓存根本没跑起来。ThinkPHP 在 APP_DEBUG=true 下会强制跳过模板缓存、关闭 SQL 查询缓存、禁用页面缓存，连 Cache::get() 都可能被绕过——这不是 bug，是设计使然。
- 上线/压测前必须确保
.env中APP_DEBUG=false，且该配置被实际加载（可临时加var_dump(config('app.debug'));验证） -
config/cache.php里'default' => 'redis'只是声明，还要检查'redis'对应的 store 是否已正确定义（host/port/auth）、Redis 服务是否可达（php -r "new Redis(); echo 'ok';"） - 文件缓存路径写错也会静默失败：比如
'path' => runtime_path() . 'cache/'，但runtime/cache/目录不存在或无写权限，缓存会退化为“假命中”（Cache::get()返回 null，不报错）
ab 压测时缓存效果被掩盖？得关掉调试干扰和冷启动偏差
用 ab -n 1000 -c 100 http://localhost/api/list 测出来 QPS 没提升，未必是缓存无效，更可能是你测的是“第一次请求”——数据库连接未复用、OPcache 未热、Redis 连接池空、缓存本身还是空的。
- 压测前手动访问一次接口预热：
curl http://localhost/api/list，再立刻跑ab；否则前几十个请求全在建连接、查 DB、生成缓存，拉低整体平均值 -
ab默认不带Cookie或Authorization，若你的缓存逻辑依赖用户身份（如“我的订单”），那所有请求都打到不同缓存 key，看起来像没缓存 - 别只看
Time per request (mean)，重点盯Time per request (mean, across all concurrent requests)和 P95 值——缓存生效后，P95 应明显下移，而平均值可能被少量慢请求拖高
缓存命中率怎么查？别只信 Cache::get() 返回值
代码里写 Cache::get('user_123') 返回了数据，不代表它从 Redis 读的——可能刚被 set() 过，也可能 fallback 到 file 驱动，甚至只是 PHP 数组模拟缓存（开发环境常见）。
- 在 Redis 服务端直接监控：
redis-cli info | grep -E "(keyspace_hits|keyspace_misses)"，算出命中率 = hits / (hits + misses)，低于 80% 就得查为什么 miss 太多 - 给缓存加统一前缀（
'prefix' => 'tp6_shop_'）并在 Redis 中keys tp6_shop_*手动验证 key 是否真实存在、TTL 是否合理 - 开启 ThinkPHP 的缓存日志（
config/cache.php中设'record' => true），日志里会明确写出 driver、key、hit/miss、耗时，比猜强得多
缓存策略写错，反而拖慢性能？警惕 N+1 和标签滥用
加了 Redis 缓存，QPS 却下降，常见原因是缓存逻辑本身成了瓶颈：比如循环里反复调 Cache::get() 查 100 个用户头像，或用 Cache::tag('user')->get('profile_123') 却没配好 tag_prefix，导致每次写都扫全库。
立即学习“PHP免费学习笔记（深入）”；
- 避免在 foreach 中单条查缓存：改用
Cache::get(['key1', 'key2', ...])批量获取（Redis 驱动支持 pipeline） - 缓存标签不是免费的：Redis 标签底层靠
set存 key 列表，clear('user')会先查列表再删 key，高并发下易成热点；高频更新场景建议不用标签，改用带业务含义的 key 命名（如user:123:profile_v2） - 页面缓存（
View::cache()）慎用于含用户态内容的页面，否则缓存的是“张三的首页”，李四打开也是张三的数据——得配合Cache::remember()或动态片段缓存
