ThinkPHP缓存故障源于默认配置与高并发模型不匹配：文件驱动易因异常中断、并发写入、编码不一致导致unserialize报错；Redis需调优timeout、host及password；Memcached须启用二进制协议并避免hosts轮询；File驱动tag限流失效，必须切Redis；权限混乱需递归修正runtime目录属主。
ThinkPHP缓存驱动在高并发场景下容易触发文件损坏、权限冲突、计数失效、连接阻塞等底层故障，这些不是偶发异常，而是由默认配置与并发模型不匹配直接导致的硬伤。
文件缓存写入损坏引发unserialize报错
第一步：确认错误是否表现为unserialize(): Error at offset X of Y bytes——这说明缓存文件内容已被破坏，而非数据本身有问题。
第二步：检查服务器是否经历过异常断电或强制kill进程，这类中断会让File驱动正在写入的序列化字符串只落盘一半，后续读取必然失败。
第三步：排查并发写入冲突——当多个PHP-FPM子进程同时对同一缓存键（如user:1001）执行Cache::set()，文件驱动无原子锁机制，极易产生混合写入，生成非法序列化字符串。
立即学习“PHP免费学习笔记（深入）”；
第四步：验证字符编码一致性——若项目中部分模块用UTF-8、部分用GBK处理含中文的缓存数据，serialize()记录的字符串长度会与实际字节数不符，反序列化时直接报错。此问题在跨环境部署（如开发机GBK→生产机UTF-8）时高频出现。
Redis驱动连接超时卡死请求
直接改.env里的CACHE_DRIVER=redis并不能解决高并发下的连接雪崩，必须同步调整超时参数。
将redis.timeout=3和redis.read_timeout=3写入.env——ThinkPHP默认值为-1（无限阻塞），一旦Redis响应延迟，整个PHP请求线程会被挂起，Nginx很快返回502。
【redis.host别写127.0.0.1】——IPv6解析可能引入毫秒级延迟，在万级QPS下足以拖垮整条链路；改用localhost或显式指定127.0.0.1:6379可绕过DNS查找。
如果Redis启用了密码，redis.password必须是非空字符串；空字符串会被Predis客户端当作“无密码”处理，导致AUTH命令失败，连接池持续新建连接却无法认证。
Memcached驱动性能反降
方法一：启用二进制协议——在config/cache.php的memcached配置块中加入'options' => [\Memcached::OPT_BINARY_PROTOCOL => true]，否则默认文本协议会产生大量冗余解析开销。
方法二：避免使用hosts数组配置多节点——ThinkPHP不支持Memcached自动分片，['192.168.1.10', '192.168.1.11']只会轮询连接，实际只用第一个节点；真要分布式，得自己管理多个Memcached实例并手动路由。
注意：Memcached不支持TTL设为0，设成0会自动转为30天；想长期缓存必须用大于2592000（30天）的秒数，否则业务逻辑会误判过期行为。
Cache::tag()限流在高并发下完全失效
根本原因：默认File驱动的get()和set()非原子操作，同一毫秒内多个请求读到相同旧值，各自+1后写回，最终计数比真实请求数少得多。
必须切换缓存驱动为Redis，并确保config/cache.php中'default' => 'redis'已生效——文件驱动下$cache->inc($key)会静默降级，根本不报错，但计数永远不准。
限流键必须携带唯一标识，例如'rate_limit_' . $request->ip() . '_' . $action；只用$action会导致所有IP共享一个计数器，误杀正常用户。
【inc()首次调用返回1】——判断逻辑必须写成if ($count > $limit)，写成>=会把第一次请求就拦截掉。
缓存目录权限混乱导致部分写入失败
ThinkPHP File驱动按缓存键MD5值前两位创建二级目录（如runtime/cache/fa/），而root用户执行php think cache:clear会以root身份创建该目录，后续www用户进程无法在其中新建文件。
只对runtime目录设777没用——必须确保所有子目录（包括cache/fa/、cache/b2/等）的所有者都是www用户，或统一用chown -R www:www runtime/递归修正。
这一步操作起来很简单，直接执行chown -R www:www runtime/就行，但漏掉任意一个二级子目录都会让对应哈希段的缓存永久失效。
