zlib压缩内存数据应先确认compress()和uncompress()的边界条件；二者是最轻量接口，适用于小数据量。
zlib 压缩内存数据：先确认 compress() 和 uncompress() 的边界条件
这两个函数是 zlib 最轻量的内存压缩接口，适合小数据量（解压。它们不支持流式处理，也不自动管理内存——你必须提前分配好输出缓冲区，并传入其大小指针。
常见错误是传入的 destLen 指针未初始化，或指向的值小于实际所需空间，导致返回 Z_BUF_ERROR；更隐蔽的问题是：解压时若输入数据被截断或损坏，uncompress() 可能静默返回 Z_DATA_ERROR 而不抛异常，容易被忽略。
-
compress()要求目标缓冲区大小至少为compressBound(srcLen)返回值，不能凭经验估算 - 解压前务必检查原始压缩数据长度是否 ≥ 4 字节（zlib header 最小长度），否则直接跳过调用
- 返回值必须显式判断：
Z_OK才代表成功；Z_MEM_ERROR表示堆内存不足（少见但可能发生在嵌入式环境）
uLong destLen = compressBound(srcLen);
Bytef* dest = new Bytef[destLen];
int ret = compress(dest, &destLen, src, srcLen);
if (ret != Z_OK) {
// 处理错误，不要假设 destLen 仍有效
}
// 注意：destLen 此时已被写入真实压缩后长度用 z_stream 手动管理流式压缩：避免 deflateInit() 后忘记 deflateEnd()
当需要分块压缩、控制压缩级别、或复用压缩上下文时，必须使用 z_stream 结构体 + deflate* 系列函数。这是生产环境更可控的方式，但生命周期管理极易出错。
最常踩的坑是：在 deflateInit() 成功后，因异常提前退出而未调用 deflateEnd()，导致 zlib 内部分配的内存泄漏（尤其在循环中反复创建时）；另一个是误将 z_stream 当栈变量传递给异步回调，而回调执行时该变量已析构。
立即学习“C++免费学习笔记（深入）”；
-
deflateInit2()第二个参数可设压缩级别（Z_DEFAULT_COMPRESSION或 -1~9），负值启用 gzip header（即生成 .gz 兼容格式） - 每次调用
deflate()前，必须设置strm->next_in、strm->avail_in、strm->next_out、strm->avail_out，且不能重叠 - 压缩结束需调用
deflate(strm, Z_FINISH)，并循环直到返回Z_STREAM_END，否则输出不完整
z_stream strm;
strm.zalloc = Z_NULL; strm.zfree = Z_NULL; strm.opaque = Z_NULL;
int ret = deflateInit2(&strm, Z_BEST_COMPRESSION, Z_DEFLATED, 15+16, 8, Z_DEFAULT_STRATEGY);
if (ret != Z_OK) return ret;
<p>strm.next_in = const_cast<Bytef*>(src);
strm.avail_in = srcLen;
strm.next_out = dest;
strm.avail_out = destSize;</p><p>while (strm.avail_in > 0) {
ret = deflate(&strm, Z_NO_FLUSH);
if (ret != Z_OK) break;
}
ret = deflate(&strm, Z_FINISH); // 必须收尾
deflateEnd(&strm); // 必须释放解压时识别输入格式：gzip、zlib、raw deflate 三者不能混用
zlib 库默认按「zlib 格式」解压（RFC1950），但网络传输或文件读取的数据可能是 gzip（RFC1952）或 raw deflate（RFC1951）。若格式不匹配，inflate() 会立即返回 Z_DATA_ERROR，而不是尝试自动探测。
关键区别在头部字节：zlib 以 0x78 开头（常见 0x78 0x01, 0x78 0x9C）；gzip 以 0x1F 0x8B 开头；raw deflate 无标准 header。强行用 zlib 模式解 gzip 数据，前两个字节就会校验失败。
- 解压前可用前两字节快速判断：
if (data[0] == 0x1F && data[1] == 0x8B)→ 用inflateInit2(&strm, 16+MAX_WBITS) - 若确定是 raw deflate（如某些协议自定义封装），用
inflateInit2(&strm, -MAX_WBITS)（负窗口位数） - 永远不要依赖
inflate()自动识别格式——它不会
C++ RAII 封装要点：别让 z_stream 的手动管理污染业务逻辑
裸用 z_stream 容易漏掉 deflateEnd()/inflateEnd()，也难统一错误处理。用 RAII 封装是必要选择，但要注意几个细节：
- 移动构造/赋值必须置空源对象的
strm->opaque，否则双重deflateEnd()会 crash - 不要在构造函数里调用
deflateInit2()并吞掉错误——应让调用方感知初始化失败 - 压缩/解压方法应返回
std::pair<int size_t></int>：前者是 zlib 错误码，后者是本次处理的有效字节数，方便上层做流控 - 避免在析构函数里抛异常（
deflateEnd()理论上也可能失败），一律用返回值或日志
真正容易被忽略的是：zlib 的压缩率和速度高度依赖数据特征。对已经加密或随机性高的内存块（如 AES 加密后的密文），zlib 压缩率趋近于 0，甚至膨胀。上线前务必用真实数据样本跑压测，而不是只测文本或图片。
