zlib c api 无 zlib_compress() 函数，需用 deflate/inflate 手动管理流；推荐 miniz 的 mz_compress2() 处理字符串，注意输出缓冲大小、const data() 越界及解压时输入格式（zlib 流首字节为 78，非 1f 8b）。
zlib_compress() 和 zlib_uncompress() 不能直接用
很多人一上来就搜 zlib_compress，发现根本没这函数——zlib C API 里压根不提供“一键压缩字符串”的封装。它只暴露 deflate() 和 inflate() 这类状态机式接口，得自己管理 z_stream、分配输出缓冲、处理流边界。直接传 std::string 进去会崩溃或返回 Z_STREAM_ERROR。
实操建议：
- 别手写
deflateInit/deflate/deflateEnd全流程，除非你真要流式压缩大文件 - 用
compress()/uncompress()（zlib 提供的简化函数），但注意：它们要求输出缓冲大小已知，得先用compressBound()预估上限 - 对
std::string操作时，输出std::vector<uint8_t></uint8_t>比char*更安全，避免 signed/unsigned char 转换导致的截断
miniz 的 mz_compress2() 更适合字符串场景
miniz 是单头文件 zlib 替代品，API 更贴近直觉。它的 mz_compress2() 支持直接传入源数据长度和目标缓冲大小，还能通过 MZ_DEFAULT_COMPRESSION 控制压缩级别，省去手动调 deflateSetDictionary 的麻烦。
常见错误现象：
立即学习“C++免费学习笔记（深入）”；
- 传入的输出缓冲太小，函数返回 0 且不写任何数据（不是 -1！）
- 把
std::string::data()当作可写缓冲传给 miniz，结果越界写入（std::string的 data() 在 C++11 后是 const 的） - 忽略返回值是压缩后字节数，直接用
std::string(output_buf, len)构造，但没检查是否为负（失败时返回负错误码）
示例关键片段：
std::string compress_string(const std::string& s) {
std::vector<uint8_t> out(mz_compressBound(s.size()));
int len = mz_compress2(out.data(), &out.size(),
reinterpret_cast<const uint8_t*>(s.data()),
s.size(), MZ_DEFAULT_COMPRESSION);
return len >= 0 ? std::string(reinterpret_cast<char*>(out.data()), len) : "";
}
解压失败常因输入被截断或带额外字节
zlib 解压对输入极其敏感：少一个字节、多一个字节、开头混入 HTTP 头（比如 "HTTP/1.1 200 OK\r\n..."），都会报 Z_DATA_ERROR。这不是 bug，是 zlib 严格校验 Adler-32 和流结构的结果。
使用场景中容易踩的坑：
- 从网络读取压缩数据时，用
recv()分多次接收，但没拼完整就调uncompress()→ 解压失败 - Base64 解码后忘了去掉末尾的
\0或换行符，导致传入inflate()的数据末尾有垃圾字节 - 误把 gzip 格式当 zlib 流（gzip 有魔数
1f 8b，zlib 是78开头），直接喂给uncompress()→Z_DATA_ERROR
验证方法：用 hexdump -C 看前两字节，zlib 压缩流通常是 78 01、78 9c 或 78 da；如果是 1f 8b，得用 gzopen() 或 miniz 的 mz_gzdecompress()。
Windows 上链接 zlib 库容易漏 ZLIB_WINAPI
在 Windows 下用 MSVC 链 zlib.lib，如果没定义 ZLIB_WINAPI 宏，调用 compress() 时会报 LNK2019: unresolved external symbol _compress。这是因为 zlib 的 Windows 版默认用 __stdcall 调用约定，而 C++ 默认是 __cdecl，符号名不匹配。
解决方式只有两个有效选择：
- 编译时加预处理器定义：
/D ZLIB_WINAPI（MSVC）或-DZLIB_WINAPI（GCC/Clang） - 改用动态链接版本
zlibwapi.dll，它导出的是__cdecl符号，不用额外宏
miniz 完全规避这个问题——它是头文件实现，所有函数内联或静态链接，不涉及调用约定冲突。
实际用的时候，最麻烦的往往不是压缩逻辑本身，而是确认输入数据确实是纯 zlib 流、没被中间件悄悄转成 gzip、也没在 base64 解码时吞掉末尾等号或加了 BOM。这些细节不打日志很难定位。
