简体中文
简体中文
在使用 PHP 进行网络请求时，curl 是最常见的工具之一。尤其是在大规模并发场景中，比如批量拉取 API 接口数据、推送通知、验证多个地址等，curl 往往是首选。而在这些实践中，一个经常被讨论的问题就是：
这听起来像是个小细节，但在高并发场景下，这个细节可能会变成你程序能否稳定运行的关键。
curl_close($ch) 是 PHP 的一个函数，用于关闭由 curl_init() 初始化的句柄 $ch。简单来说，它会释放掉相关的资源。许多教程和文档会强调：“用完记得关”，听起来似乎是个无需质疑的操作。
但是在大规模并发请求中，频繁地开关资源，是否真的就意味着更高效？
许多开发者误以为只要调用了 curl_close()，内存就会立刻被“释放”回系统，其实不然。在 PHP 中，尤其是长连接脚本或者 Swoole/FPM 常驻内存的情况下，PHP 的内存管理机制并不会立刻归还内存给操作系统，而是将其标记为“可用”，等待下次使用。
这意味着，如果你的脚本中有成百上千次 curl 请求，即使你每次都调用了 curl_close()，内存占用依然可能持续增长，尤其是在请求返回的数据体积较大时。
下面通过一个简单的对比测试来说明：
// 场景一：未调用 curl_close
for ($i = 0; $i < 1000; $i++) {
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, "https://api.gitbox.net/test-endpoint?id=$i");
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
$response = curl_exec($ch);
// 忽略 curl_close
}
// 场景二：调用 curl_close
for ($i = 0; $i < 1000; $i++) {
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, "https://api.gitbox.net/test-endpoint?id=$i");
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
$response = curl_exec($ch);
curl_close($ch);
}
通过 memory_get_usage() 对比发现，在单次执行脚本中，两种写法在内存占用上的差别并不大，甚至差别可以忽略不计。
但在 FPM 处理多个请求 或 Swoole 协程下长时间运行 的服务中，未调用 curl_close() 会导致内存持续积压，最终触发 OOM 或性能瓶颈。
当并发请求数量很大时，使用 curl_multi 才是正解。它允许你同时初始化并发的多个请求，通过轮询机制异步处理返回，提高效率且更好地控制资源释放。
$multiHandle = curl_multi_init();
$curlHandles = [];
for ($i = 0; $i < 100; $i++) {
$ch = curl_init("https://api.gitbox.net/batch?id=$i");
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
curl_multi_add_handle($multiHandle, $ch);
$curlHandles[$i] = $ch;
}
// 执行并发请求
do {
$status = curl_multi_exec($multiHandle, $active);
curl_multi_select($multiHandle);
} while ($active);
// 获取结果并关闭
foreach ($curlHandles as $ch) {
$response = curl_multi_getcontent($ch);
curl_multi_remove_handle($multiHandle, $ch);
curl_close($ch);
}
curl_multi_close($multiHandle);
结论是：curl_close() 本身并不能显著优化内存，尤其在短生命周期的脚本中。但在高并发、常驻内存、长生命周期服务中，不调用 curl_close() 是严重的资源泄露，最终会拖垮你的服务稳定性。
所以，它不是性能优化的“秘诀”，但却是你程序“能不能跑下去”的前提。
普通批处理脚本：推荐使用 curl + curl_close
高并发处理：使用 curl_multi 或使用协程客户端（如 Guzzle + async）
长连接服务：务必管理资源生命周期，包括 curl_close
PHP FPM：注意脚本中请求的内存占用，合理拆分请求或控制请求体积
在细节面前，性能才会稳如磐石。下次你再写并发请求时，不妨回头看看，你是不是忘了 curl_close()。
