持久连接可能减少重复建连成本，但也会保留连接、占用资源，并影响故障后的重建行为。是否启用要看PHP进程模型、客户端实现和实际延迟。不能把单次连接耗时减少，直接当成整站必然提速的证据。
复用范围由进程决定
PHP-FPM通常有多个工作进程，持久连接的复用行为与进程生命周期及客户端有关，不是全站只保留一条连接。先记录工作进程规模、客户端和连接标识，估算正常与峰值连接数。不要用一次命令行脚本的表现推断网站长期运行的连接模式。
连接数量需要服务端承受
进程增加、站点数量增长和后台任务都可能增加连接占用。观察Redis连接统计、客户端限制和PHP进程变化，区分正常复用与异常泄漏。持久连接若降低了建连次数，却让闲置连接长期占满额度，整体可用性反而可能受影响。
故障后重用旧连接要检查
网络设备可能关闭闲置连接，Redis重启或切换也会使旧连接失效。客户端应能按支持方式识别失败并重建，相关超时和重试需要纳入页面预算。不能把保持连接与网络保活混为一谈，也不能靠无限重试维持表面成功。
用代表流量比较收益
分别观察建连次数、请求延迟、连接总量与错误率，保持相近业务条件。对远程TLS连接和本机连接，收益可能不同，不能给统一提升数字。启用后至少覆盖一次进程轮换和服务恢复的受控验证，再决定长期保留还是回退。
关键区别
持久连接：跨请求复用；受进程范围影响。
连接额度：服务端资源；需考虑峰值。
网络保活：检测闲置链路；不等于无限可用。
怎样确认处理到位
验证应同时证明连接数量处于预算内、故障后可按预案恢复，并有相近条件的页面延迟对比。只有连接次数下降，仍不足以说明用户体验改善。
容易误判的边界
不要为每个请求生成不同持久连接标识，也不要忽略多PHP池和任务进程。配置项是否支持字符串标识等细节，以当前插件和客户端版本为准。
