17370845950

直接用libcurl C API写C++易出问题，因其无RAII、异常安全和自动资源管理，易致cleanup遗漏、异常泄漏、悬垂句柄；需封装CURL*句柄、缓冲区、errorbuffer并正确处理回调与错误。

为什么直接用 libcurl C API 写 C++ 容易出问题

libcurl 是纯 C 接口，没有 RAII、异常安全或自动资源管理。裸用 curl_easy_init() + curl_easy_perform() + curl_easy_cleanup() 很容易漏掉 cleanup、在异常路径下内存泄漏、或误传裸指针导致悬垂句柄。C++ 封装的核心不是“套一层 class”，而是把生命周期、错误传播、选项设置这三件事收束到对象语义里。

封装类必须管理的三个关键资源

一个最小但健壮的 CurlClient 类至少要封装：

• CURL* 句柄：必须在构造时 curl_easy_init()，析构时 curl_easy_cleanup()，且禁止拷贝（禁用拷贝构造/赋值），只支持移动
• std::string 缓冲区（用于 CURLOPT_WRITEFUNCTION）：避免用户传入栈变量地址被回调写越界；缓冲区生命周期必须与请求强绑定
• CURLOPT_ERRORBUFFER 对应的 char[256]：必须保留在对象内，否则 curl_easy_strerror() 无法反映真实错误

示例中常见错误是把 errorbuf 声明为局部数组再传给 curl_easy_setopt()，一出作用域就失效。

如何正确设置回调函数和用户数据

libcurl 的回调函数（如 WRITEFUNCTION、READFUNCTION）必须是 C 风格函数指针，不能直接传 lambda 或成员函数。标准解法是用静态成员函数 + void* 用户数据传递 this 指针，但要注意：该指针在回调触发时必须仍有效——也就是说，不能在异步调用（如 curl_easy_perform() 返回后才触发回调）中提前析构对象。

立即学习“C++免费学习笔记（深入）”；

同步请求可直接用 this；若支持异步，需用 std::shared_ptr 管理对象生命周期，并确保回调中调用 shared_from_this() 或类似机制。

关键参数设置示例：

curl_easy_setopt(handle, CURLOPT_WRITEFUNCTION, &CurlClient::write_callback);
curl_easy_setopt(handle, CURLOPT_WRITEDATA, this);

对应静态回调函数必须声明为：

static size_t write_callback(void* ptr, size_t size, size_t nmemb, void* userp) {
    auto* self = static_cast(userp);
    // …
}

错误处理不能只靠返回值

curl_easy_perform() 返回 CURLE_OK 只代表传输层没出错，不代表 HTTP 状态码是 2xx。必须显式调用 curl_easy_getinfo(handle, CURLINFO_RESPONSE_CODE, &http_code) 获取状态码。同时，CURLOPT_FAILONERROR 设为 1 后，4xx/5xx 会令 curl_easy_perform() 返回非零，但它不改变重定向行为（如 302 仍会自动跳转），也不捕获 DNS 解析失败等底层错误。

建议封装中统一提供：

• int http_status_code()：返回最后响应的 HTTP 状态码
• const char* error_message()：返回 error_buffer 中内容，而非仅依赖 curl_easy_strerror()
• bool ok()：综合判断：libcurl 返回值为 CURLE_OK 且 http_status_code() >= 200 && http_status_code()

别忽略 CURLOPT_NOSIGNAL：在多线程环境中未设此选项，DNS 超时可能引发 SIGPIPE 或 SIGALRM，导致整个进程退出。