PHP 8.5 curl_share_init_persistent() 怎么复用连接：DNS、连接锁与跨请求验收

PHP-FPM 场景下每次请求都访问同一组 HTTPS 服务时，DNS 解析和连接初始化操作会反复执行，哪怕是很短的请求，也可能被这些固定开销拖慢速度。PHP 8.5 新增的 curl_share_init_persistent() 允许配置了相同共享选项的 cURL 共享句柄跨请求复用，适合在有稳定上游、可观测指标齐全、明确配置了回滚开关的服务集群中做小比例验证。

这个能力首先要验收“共享选项一致、FPM 进程范围正确、连接锁可用”，再看 DNS 时间、连接建立时间和 P95 延迟是否真的下降；它不是把所有 cURL handle 变成全局连接池。

PHP 8.5 的持久共享句柄解决哪一段成本

PHP 官方 8.5 更新说明把这个能力描述为持久 cURL share handle：后续请求只要使用完全相同的共享选项，PHP 就可以直接找到并复用已有的共享句柄，省去重复初始化的步骤。它作用的是 DNS、连接等可共享的公共数据，不等同于复用正在传输的请求，也不会跳过每次请求自己的 URL、请求头和响应处理逻辑。

因此验收要把“初始化成本下降”和“请求语义保持不变”分开验证。先固定上游地址、请求方法和响应校验规则，再只切换共享句柄实现，避免同时更换 HTTP 客户端其他参数导致结果不可对比。

先固定 CURL_LOCK_DATA_DNS 与 CURL_LOCK_DATA_CONNECT

最小示例可以从两个共享配置项开始写：

示例里的共享句柄只负责提供共享能力，还是需要逐请求单独设置 URL、超时、证书校验规则和返回码检查逻辑。不要为了观察复用效果就关闭 TLS 校验，也不要把用户级 Cookie 或授权状态放到跨请求共享的范围内。

用三段时间证明复用而不是凭感觉

给每次请求记录 cURL 的计时信息：CURLINFO_NAMELOOKUP_TIME、CURLINFO_CONNECT_TIME 和 CURLINFO_STARTTRANSFER_TIME。连续请求访问同一上游时，重点比较第二次及之后请求的耗时分布，不要只拿单次最快的样本下结论。

同时统计响应码、证书错误、超时数量和上游限流次数。如果 DNS 耗时下降但连接错误率上升，说明优化收益和服务稳定性发生了交换，不能只靠平均延迟判断优化是否有效。

在 PHP-FPM 灰度中保留普通路径

建议用配置开关控制持久共享能力的开启：关闭时继续使用 curl_share_init()，开启时才调用 PHP 8.5 的新函数。先选中少量 worker 或者小比例流量，观察至少一个完整业务高峰的表现，再决定是否扩大覆盖范围。

回滚条件要提前确认好：上游 5xx、TLS 错误、连接超时、FPM worker 占用过高或 P95 耗时超过基线时就直接关闭开关。回滚后再对比三段耗时指标，确认问题来自新的共享路径，而不是 DNS 波动、上游负载变化或发布操作本身带来的影响。

常见问题

curl_share_init_persistent() 会跨服务器共享连接吗？

不会把状态同步到其他服务器。它的复用范围受 PHP 进程和运行环境限制，负载均衡后的不同实例需要分别观察指标。

共享句柄能复用登录 Cookie 吗？

不要这样设计。共享 DNS 或连接初始化和用户身份隔离是两个独立逻辑，Cookie、授权头和响应内容都要按请求单独管理。

为什么连接复用后 P95 反而升高？

可能是共享锁竞争、上游连接策略或 worker 分布不均造成的。先按 worker 维度拆分指标，再关闭开关做对照测试，不要只看平均值判断问题。

总结

PHP 8.5 的持久 cURL share handle 适合优化重复访问同一上游时的初始化成本。把共享选项、FPM 范围、安全隔离和三段计时一起纳入验收范围，才能确认收益真实，也能在出现异常时快速退回普通路径。