必须根据 Content-Encoding: gzip 响应头判断是否解压，zlib inflate 初始化须用 -MAX_WBITS；解压缓冲区需动态预估，流式解压需配合 HTTP 分块传输正确管理 inflate 状态。
直接解压即可，但必须注意 Content-Encoding: gzip 响应头存在时，zlib 解压参数不能用默认值——否则会失败或返回乱码。
如何判断响应体是否被 gzip 压缩
HTTP 响应头中出现 Content-Encoding: gzip 是唯一可靠依据。不能仅凭文件后缀（如 .gz）或魔数（0x1f 0x8b）盲目解压，因为：
- 有些服务在未协商
Accept-Encoding: gzip时仍可能返回 gzip（违反规范但真实存在） - 某些代理或 CDN 可能篡改或删除该 header，导致误判
-
Content-Length字段值对压缩后数据有效，但无法反推是否压缩
zlib inflate 初始化必须用 -MAX_WBITS
这是最常踩的坑：inflateInit2(&strm, -MAX_WBITS) 中的负号不能省。原因在于：
-
MAX_WBITS（15）表示原始 DEFLATE 流，不含 gzip header/trailer - HTTP 响应中的 gzip 数据带标准 header（
0x1f 0x8b）和 footer（校验、长度），必须用-15让inflate自动跳过它们 - 若误用
MAX_WBITS或MAX_WBITS + 16（后者是压缩时用的），inflate会卡在 header 解析阶段，返回Z_DATA_ERROR
示例关键代码：
立即学习“C++免费学习笔记（深入）”；
z_stream strm;
strm.zalloc = Z_NULL;
strm.zfree = Z_NULL;
strm.opaque = Z_NULL;
strm.avail_in = gz_data_len;
strm.next_in = reinterpret_cast<Bytef*>(gz_data_ptr);
// 必须用负值！
if (inflateInit2(&strm, -MAX_WBITS) != Z_OK) {
// handle error
}
strm.avail_out = out_buf_size;
strm.next_out = out_buf;
int ret = inflate(&strm, Z_FINISH);
if (ret == Z_STREAM_END) {
// success, decompressed size = strm.total_out
} else if (ret == Z_DATA_ERROR) {
// 检查是否真为 gzip 数据（比如 header 被截断）
}
inflateEnd(&strm);
解压缓冲区大小要预估，不能硬写固定值
gzip 解压后体积不可控，尤其文本类响应可能膨胀数倍。常见错误是分配 4KB 缓冲却去解压 1MB 原始内容：
- 用
Content-Length（压缩后长度）完全无法预测解压后大小 - 安全做法：按压缩数据长度 × 3 预分配（多数文本场景够用），或使用动态扩容（如
std::vector<char>扩容 push_back） - 若已知原始大小（例如服务端返回了
X-Original-Size自定义 header），可直接按该值分配
流式解压比一次性加载更实用
实际 HTTP 响应可能很大（如 API 返回的 JSON 列表），或通过 chunked encoding 分块传输。此时不应等全部数据收完再解压：
- 对每个收到的 chunk 调用
inflate()，传入Z_NO_FLUSH（除最后一块用Z_FINISH） - 注意维护
strm.avail_in和strm.next_in的偏移，避免重复解压同一段内存 - 务必检查每次
inflate()返回值：Z_OK表示继续，Z_STREAM_END表示完成，Z_BUF_ERROR表示输出缓冲满需扩容
真正难的不是调 zlib 函数，而是把解压逻辑嵌进 HTTP parser 的生命周期里——header 解析完才决定是否启用 inflate，body 收一段解一段，出错要能回退到原始字节流。这个衔接点，比压缩参数容易被忽略得多。
