直接用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() 返回后才触发回调）中提前析构对象。
同步请求可直接用 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，导致整个进程退出。
