Content-Length 字段非必需，可能因分块传输或无实体响应而缺失；解析时需先校验存在性与合法性，推荐用 std::from_chars 安全转换；不同 HTTP 库获取 header 方式各异，须依文档适配；该字段仅作参考，实际接收需结合连接状态与读取逻辑验证。
Content-Length 字段可能根本不存在
HTTP 响应头里 Content-Length 不是必有的。比如使用 chunked 编码时，服务器会省略它，改用 Transfer-Encoding: chunked；或者响应是 304 Not Modified、204 No Content 这类无实体的响应，也压根不带这个字段。
所以不能假设它一定存在，更不能直接调用类似 headers["Content-Length"] 就完事——这在多数 C++ HTTP 库里会触发越界或返回空字符串/默认值。
- 先检查响应状态码是否允许携带 body（比如 2xx、3xx 中除 304 外，以及部分 4xx）
- 再检查是否存在
Content-Length字段，且值非空 - 若不存在，再看是否有
Transfer-Encoding且其值为chunked，此时长度不可静态预知
从字符串值安全转成 size_t 的坑
Content-Length 值是 ASCII 字符串，比如 "12345"，但直接用 std::stoull() 或 std::atoi() 很危险：前者抛异常（你得 try/catch），后者遇到非法字符返回 0（而 0 是合法长度），还忽略溢出。
推荐用 std::from_chars()（C++17 起），它不抛异常、不忽略溢出、能精确报告解析终点：
立即学习“C++免费学习笔记（深入）”；
std::string_view len_str = get_header_value("Content-Length");
if (len_str.empty()) return std::nullopt;
unsigned long long len_val;
auto [ptr, ec] = std::from_chars(len_str.data(), len_str.data() + len_str.size(), len_val);
if (ec != std::errc{} || ptr != len_str.data() + len_str.size()) {
// 解析失败：含非数字字符、超范围等
return std::nullopt;
}
if (len_val > SIZE_MAX) return std::nullopt; // 防 size_t 截断
return static_cast<size_t>(len_val);
不同 HTTP 库获取 header 的方式差异大
libcurl、cpp-httplib、boost.beast、restbed 各自暴露 header 的接口完全不同，不能套用统一写法：
- libcurl：需用
CURLOPT_HEADERFUNCTION自定义回调捕获原始 header 行，再手动解析；或用curl_easy_getinfo(..., CURLINFO_CONTENT_LENGTH_DOWNLOAD)——但该值是 double 类型，且仅在传输完成后才可靠 - cpp-httplib：响应对象有
res.headers（std::map<std::string, std::string>），可直接查res.headers.at("Content-Length")，但要注意大小写不敏感匹配需自己处理 - boost.beast：用
res.base().at("Content-Length").value()，返回的是string_view，注意 lifetime
别硬记“某个函数名”，先确认你用的库文档里 header 是如何索引和生命周期管理的。
别把 Content-Length 当作实际接收字节数
它只是响应头声称的 body 长度，不代表你一定能收到那么多字节——网络中断、代理截断、SSL 解密失败都可能导致 recv 不足。尤其在非 keep-alive 连接中，服务端可能提前关闭 socket。
真正可靠的结束判断是：
- 读到指定
Content-Length字节数（且连接未关闭） - 或遇到 chunked 编码的 final chunk（
"0\r\n\r\n"） - 或底层连接关闭（且无更多数据可读）
哪怕 header 里写了 Content-Length: 1024，也得配合 read loop + error checking，不能只靠它分配缓冲区后就 blind memcpy。
