frankenphp worker模式下redis连接总断，因pconnect复用“假活”连接且未做健康检查；须每次操作前ping()验证、设read/write超时、服务端timeout设0并开启tcp-keepalive。
FrankenPHP worker 模式下 Redis 连接为什么总断？
不是 Redis 挂了，也不是网络不通，而是 PHP 进程常驻后，原生 pconnect 的连接复用逻辑和 FrankenPHP 的协程调度存在隐性冲突：连接在上一个请求结束时未被主动检测有效性，下一个请求直接复用“假活”连接，read error on connection 就立刻报出来。
典型现象是：首次请求正常，后续请求随机失败；redis-cli ping 通但 PHP 报错；phpinfo() 显示扩展已加载，php -m | grep redis 也正常——问题出在连接生命周期管理上。
-
pconnect创建的连接会绑定到当前 PHP 进程（即 FrankenPHP worker 进程），不会随请求结束销毁 - 若 Redis 服务端因超时、OOM、swap 或主从切换断开连接，该 socket 在进程内仍被标记为“可用”
- 下次请求调用
$redis->get()时，底层尝试读取已关闭的 socket，触发read error on connection
必须在每次操作前做连接健康检查
不能依赖 isConnected()，它只判断 socket 是否打开，不验证服务端是否可响应。真正有效的检测方式是带超时的 ping()。
实操建议（入口脚本或 Redis 封装类中）：
- 每次执行命令前，先调用
$redis->ping() === '+PONG'，失败则重建连接 - 务必设置
read_timeout：用$redis->setOption(Redis::OPT_READ_TIMEOUT, 1.0)，避免卡死 - 不要用
connect()全量重连，改用pconnect()并传入超时参数（如$redis->pconnect('127.0.0.1', 6379, 2.5)），让连接池自动淘汰僵死连接 - 如果用了连接池封装（如自建 pool），需在
borrowObject()时强制执行ping()，否则池里可能存着一堆“僵尸连接”
禁用 default_socket_timeout，但别设成 -1
default_socket_timeout = -1 在 FrankenPHP worker 下极其危险：一个卡住的 Redis 请求会拖垮整个协程，甚至阻塞其他请求处理。
正确做法是分层控制超时：
- 连接阶段：用
pconnect($host, $port, $timeout)的第三个参数（推荐2.5秒） - 读写阶段：用
$redis->setOption(Redis::OPT_READ_TIMEOUT, 1.0)和Redis::OPT_WRITE_TIMEOUT, 1.0) - 全局
default_socket_timeout保持默认值（60 秒）或设为5，防止底层 socket 层无限等待 - 绝不在代码里调用
ini_set('default_socket_timeout', -1)—— 这等于给协程埋雷
Redis 配置要配合 worker 生命周期
Redis 服务端的 timeout 参数（redis.conf 中）必须设为 0，否则连接会在空闲期被服务端主动断开，而 FrankenPHP worker 不会感知，继续复用已关闭的 fd。
同时注意：
- 确保
tcp-keepalive开启（默认 300 秒），让内核定期探测连接活性 - 禁用
protected-mode no仅用于调试，生产环境必须保留protected-mode yes并配好bind和requirepass - 如果用了哨兵或集群，客户端必须支持自动重定向（如
Predis），原生Redis扩展不支持集群拓扑变更后的自动故障转移
最易被忽略的一点：FrankenPHP 的 worker 进程重启频率极低，一次连接泄漏或僵死会持续数小时甚至数天，不像 PHP-FPM 那样靠进程轮换“自然恢复”。必须把连接健康检查当作每条 Redis 命令的前置条件，而不是“偶尔加一下”的优化项。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
