PHP curl_share_init 怎样共享连接资源

如果多个 PHP 请求都要访问同一个服务，直接为每次调用创建独立的 cURL 句柄并不意味着它们会自动共享连接缓存。curl_share_init() 的作用，是创建一个可以挂到多个 CurlHandle 上的共享句柄；真正共享连接、DNS、SSL 会话还是 Cookie，则要继续通过 curl_share_setopt() 明确选择。

官方地址：https://www.php.net/manual/en/

最稳妥的思路是：请求句柄负责一次请求，共享句柄只承载你明确允许复用的资源。若目标只是降低重复建连成本，先共享连接缓存；不要因为用了 curl_share_init() 就把 Cookie 或业务状态一起暴露给所有请求。

先分清两个句柄：请求句柄和共享句柄

curl_init() 返回的是一个请求用的 CurlHandle，它保存 URL、请求选项、响应和本次传输的上下文。curl_share_init() 返回的是 CurlShareHandle，它本身不负责发请求，而是保存可以被多个 cURL 句柄共享的数据。

两者的关系可以记成“多个请求句柄 + 一个可选共享句柄”。每个请求仍然要单独设置 URL、请求头和超时；共享句柄只通过 CURLOPT_SHARE 接入。这样既能复用底层资源，又不会把一个请求的响应内容误认为共享状态。

curl_share_init 只创建容器，共享范围由 curl_share_setopt 决定

curl_share_init() 没有参数，返回一个共享句柄。下一步要调用 curl_share_setopt()，把 CURLSHOPT_SHARE 和某个 CURL_LOCK_DATA_* 常量配对。官方文档把连接缓存、DNS 缓存、SSL 会话和 Cookie 数据列为不同的共享项，它们不是一个“全量共享”开关。

如果你的目标是让多个请求尽量复用相同的连接缓存，可以先从 CURL_LOCK_DATA_CONNECT 开始；如果还要减少重复解析域名或 TLS 会话建立，再按场景增加 DNS 或 SSL 会话项。每增加一项，都要重新确认请求之间是否允许共享对应状态。

这里的两个布尔返回值不能省略：curl_share_setopt() 成功返回 true，失败返回 false。把共享配置集中在初始化阶段，后续创建请求句柄时就不容易漏掉某一项。

把同一个 share handle 绑定到多个独立请求

创建好共享句柄后，对每个独立的请求句柄设置 CURLOPT_SHARE。请求句柄仍然要分别设置 URL 和返回内容选项。下面的示例把连接缓存共享给两次读取，但不启用 Cookie 共享，因此两个请求不会因为共享句柄而自动共用 Cookie 数据。

示例中的 api.example.test 只是文档保留域名，不代表可访问的服务。关键在于生命周期：先创建共享句柄，再为每次请求绑定它；请求句柄使用完就关闭，共享句柄等所有请求结束后再释放引用。

共享连接缓存，不等于共享所有请求状态

CURL_LOCK_DATA_CONNECT 解决的是连接缓存边界；CURL_LOCK_DATA_DNS 解决 DNS 缓存；CURL_LOCK_DATA_SSL_SESSION 解决 SSL 会话 ID；CURL_LOCK_DATA_COOKIE 则是 Cookie 数据。它们的用途不同，不能用“性能共享”作为启用全部选项的理由。

尤其要谨慎处理 Cookie。若两个请求代表不同用户、租户或权限上下文，通常只共享连接缓存，不共享 Cookie。否则连接层面的复用是安全的，状态层面的复用却可能造成难以定位的身份串线。

清理责任：请求句柄逐个关闭，共享句柄统一收口

PHP 8.0 起，cURL 句柄返回对象而不是旧式 resource；官方文档还说明 curl_share_close() 从 PHP 8.0 起已经是无操作函数，并在 PHP 8.5 起弃用。新代码不应把它当作必须调用的资源释放 API。

更清晰的做法是由创建共享句柄的那一层负责收口：所有使用它的请求结束后，让共享对象失去引用；在循环里则始终先关闭每个请求句柄。若代码封装成服务对象，可以把共享句柄作为对象属性，并在对象生命周期结束时统一置空。

常见误区与排查顺序

1. 只调用 curl_share_init：这只创建了容器，必须继续配置 CURLSHOPT_SHARE 和具体的 CURL_LOCK_DATA_*。
2. 把 share handle 当成请求句柄：它不能替代 curl_init()，每个 URL 仍然需要自己的 CurlHandle。
3. 启用 Cookie 共享后出现身份串线：先确认调用方是否属于同一会话或同一租户，再决定是否共享 CURL_LOCK_DATA_COOKIE。
4. 把复用连接误认为固定连接：共享连接缓存只是允许 cURL 在满足条件时复用资源，不保证每个请求都使用同一条连接。
5. 继续依赖 curl_share_close：在 PHP 8.x 中应按对象生命周期管理，不要把已弃用或无效果的函数当作核心清理动作。

结论

curl_share_init() 的正确打开方式不是“创建一个全局 cURL”，而是“创建一个可选择共享范围的资源边界”。先用 CURL_LOCK_DATA_CONNECT 处理连接缓存，再按真实需求增加 DNS 或 SSL 会话；只有确认请求可以共享身份状态时，才考虑 Cookie。请求句柄逐个关闭，共享句柄由创建者在所有使用者完成后统一收口，就能把性能收益和隔离责任同时保留下来。

相关问题

curl_share_setopt 返回 false 该怎么办？

把它当作配置失败处理，检查 cURL 扩展、共享选项和对应的 CURL_LOCK_DATA_* 常量，不要继续把未完成配置的句柄交给请求。

共享连接缓存会共享响应内容吗？

不会。响应缓冲区、URL 和请求选项仍属于各自的 CurlHandle；共享句柄只承载被明确选择的 cURL 共享数据。

PHP 8.5 还能调用 curl_share_close 吗？

官方文档已将它标记为弃用，而且 PHP 8.0 起该函数无效果。新代码应依靠对象生命周期回收，并显式关闭每个请求句柄。