TP6.x中Cache::store('redis')默认降级为File驱动，需在config/cache.php中显式配置'default'=>'redis'及'stores.redis.type'=>'redis'，且标签清理需启用'use_tag_index'=>true并确保Redis≥6.0。
ThinkPHP 5.1 和 6.x 的 Cache::store() 行为不一致
TP5.1 中 Cache::store('redis') 默认走的是 think\cache\driver\Redis，而 TP6.x 改为必须显式指定完整类名或配置驱动类型，否则会 fallback 到 File 驱动——哪怕你已配好 redis 连接信息。
常见错误现象：Cache::store('redis')->set('key', 'val') 在 TP6.x 里没报错但数据写进了 runtime/cache/ 目录，不是 Redis。
- TP6.x 必须在
config/cache.php中明确声明'default' => 'redis'，且'stores.redis.type'要设为'redis' - 调用时若仍用字符串别名，需确保该别名在
stores配置中存在并启用，否则自动降级 - TP5.1 允许通过
Cache::init(['type'=>'redis'])动态切换，TP6.x 不再支持这种运行时初始化方式
TP6.x 的 TaggedCache 在 Redis 驱动下默认不支持标签删除
你以为 $cache->tag('user')->set('1001', $data) 后能用 $cache->tag('user')->clear() 清空，结果发现没生效？这是 TP6.x + Redis 驱动的默认行为：它用的是 Redis 的 key 前缀模拟标签，clear() 只删前缀匹配的 key，但不会维护 tag 索引（即没有 zset 或 set 记录哪些 key 属于哪个 tag）。
- 要真正支持标签级清理，必须手动启用
'use_tag_index' => true配置项，并确保 Redis 版本 ≥ 6.0（因依赖SCAN+DEL批量操作） - 开启后每次
set()会多写一条ZADD tag:user timestamp key，带来约 15%~20% 写入开销 - TP5.1 的
TagLib实现是基于文件扫描的，天然不支持原子性标签清理，所以 TP6.x 这个“可选增强”其实是关键升级点
TP5.1 的 SimpleCache 接口适配器在 TP6.x 中被移除
如果你把 TP5.1 写的缓存工具类直接挪到 TP6.x，调用 new \think\Cache\Driver\SimpleCache(new Redis()) 会报错：Class 'think\Cache\Driver\SimpleCache' not found。TP6.x 已彻底移除对 PSR-16 SimpleCache 的封装层，改用原生 think\cache\driver\Redis 实例直接实现 get/set 等方法。
立即学习“PHP免费学习笔记（深入）”；
- 迁移时不要试图找替代类，直接用
Cache::store('redis')返回的对象即可，它已实现全部 PSR-16 方法 - 注意 TP6.x 的
set()第三个参数不再接受DateTimeInterface，只认 int 秒数；TP5.1 支持传new \DateTime('+1 hour') - TP5.1 的
remember()是闭包延迟计算，TP6.x 的同名方法签名未变，但底层触发时机略有差异：TP6.x 会在请求结束前统一 flush 缓存队列，TP5.1 是立即写入
Redis 驱动在 TP5.1 和 TP6.x 中的连接复用机制不同
TP5.1 的 Redis 驱动默认每次请求新建连接（除非你手动配置了 pconnect），而 TP6.x 默认启用 pconnect（长连接），但有个隐藏坑：如果 PHP-FPM 子进程重启，旧的 Redis 连接句柄不会自动 close，可能引发 READ Timeout 或 Connection reset by peer。
- TP6.x 建议在
config/cache.php中显式设置'host','port','timeout','pconnect' => false来规避连接残留问题，尤其在高并发短连接场景 - TP5.1 若想用长连接，得在
cache.php里加'options' => ['pconnect'=>true]，但要注意 Redis 服务端maxclients配置是否足够 - 两个版本都建议监控
redis-cli info clients | grep connected_clients，避免连接数爆炸
缓存驱动升级最麻烦的从来不是 API 对齐，而是那些没写进文档的默认行为偏移——比如 TP6.x 的 tag 索引开关、连接复用策略、甚至序列化方式（TP6.x 默认用 igbinary 如果扩展存在，TP5.1 固定用 serialize）。上线前务必用真实流量压测缓存命中率和连接稳定性。
