根本原因是pconnect()未指定稳定persistent_id时，php-fpm各worker进程独立管理无名连接池，导致并发下重复建连；需用固定字符串id并启用check_alive与ping校验。
为什么pconnect()在PHP 7.4下会创建大量长连接
根本原因不是pconnect()本身有问题，而是它默认不带persistent_id参数时，每次调用都会尝试复用“无名”的持久连接池——但PHP-FPM每个worker进程内部对无ID连接的管理是独立的，且无法跨进程识别同一连接。结果就是：100个并发请求进来，可能触发100个看似“复用”实则各自新建的连接，尤其在pm.max_requests设为非零值时，旧进程残留的连接不会被释放，Redis端connected_clients持续上涨。
persistent_id怎么填才真正生效
必须显式传入一个**稳定、有业务含义的字符串**，不能是动态生成或依赖请求上下文的值（比如session_id()或$_SERVER['REQUEST_URI']）。否则不同请求会落到不同连接池，起不到复用效果。
-
$redis->pconnect('127.0.0.1', 6379, 2.5, 'user_cache')✅ 合法，命名清晰，复用可控 -
$redis->pconnect('127.0.0.1', 6379, 2.5, uniqid())❌ 每次都新建池，比不用还糟 -
$redis->pconnect('127.0.0.1', 6379)⚠️ 无ID，PHP内部用哈希推导ID，易冲突且不可控
验证是否生效：压测前后执行redis-cli client list | grep -c "addr="，连接数应基本持平；若只增不减，说明persistent_id已起作用。
PHP 7.4 + phpredis 5.x 的兼容性陷阱
phpredis 5.0+ 默认启用zend_register_persistent_resource_ex机制，但PHP 7.4的资源清理逻辑和早期版本有差异——如果redis.pconnect.check_alive = 1未开启，失效连接不会自动剔除，导致连接池里积压“僵尸连接”。
- 务必在
php.ini中确认以下三项已设置：redis.pconnect.connection_limit = 256redis.pconnect.timeout = 2.5redis.pconnect.check_alive = 1 - 代码中仍需手动
ping()：调用前加if ($redis->ping() !== '+PONG') { throw new Exception('Redis dead'); }，不能全信配置 - 若用Swoole常驻进程，
persistent_id反而容易泄漏——此时应弃用pconnect()，改用topthink/think-redis的pool配置或co\redis协程客户端
ThinkPHP 6 配置里'persistent' => true为什么没用
因为TP6底层用的是Redis类封装，而'persistent' => true这个配置项**仅对原生Redis扩展的pconnect()生效，对Predis完全无效**。如果你的composer.json里同时存在predis/predis，TP会优先走Predis，此时persistent配置被静默忽略。
- 检查实际加载的驱动：
var_dump(config('cache.default'))，确认type是redis而非predis - 强制使用phpredis：在
config/redis.php中删掉predis相关依赖，或在composer remove predis/predis - 真正起作用的配置是
'host'、'port'、'timeout'和'persistent_id'（需自行注入到实例化逻辑中）
最易被忽略的一点：连接复用是否成功，不取决于你写了多少配置，而取决于persistent_id是否全局唯一且稳定、以及Redis服务端是否开启了tcp-keepalive 60。中间网络设备（如阿里云SLB）静默断连后，PHP端可能还在用失效连接，必须靠ping()+check_alive双保险兜底。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
