zlib的deflate与gzip格式不同：deflate默认输出无头尾的原始流，而gzip需10字节头（含magic、mtime等）和8字节尾（CRC32+原大小），正确方式是用windowBits=31启用自动封装或手动构造头尾并严格处理CRC32（小端、0xEDB88320多项式、初始/终值异或0xFFFFFFFF）及流式调用逻辑。
zlib 的 deflate 和 gzip 格式不是一回事
直接调用 deflate 默认只生成原始 DEFLATE 流（无 header、无 trailer），而 .gz 文件必须包含 gzip 封装头（10 字节 magic + flags + mtime 等）和 8 字节尾部（CRC32 + uncompressed size）。很多初学者误以为设置 Z_BEST_COMPRESSION 就能输出标准 gzip，结果解压失败或被识别为“unknown format”。
正确做法是：要么手动构造 gzip header/trailer 并用 deflate 压缩 payload，要么用 zlib 提供的 gzopen/gzwrite 系列函数 —— 它们自动处理封装，但仅适用于文件 I/O 场景。
- 若需内存中压缩成完整
.gz字节流（比如网络传输、嵌入资源），必须手写 header/trailer，不能跳过 CRC32 计算和 little-endian 字节序处理 -
gzopen("file.gz", "wb")看似简单，但它内部依赖fopen，无法用于无文件系统环境（如嵌入式、WebAssembly） - header 中的
OS字段建议填3（Unix）或10（Windows），填0（FAT）可能被某些解压工具忽略时间戳
用 deflateInit2 启用 gzip wrapper 需设对 windowBits 参数
zlib 允许通过 windowBits 控制输出格式：windowBits = 15 是原始 DEFLATE，windowBits = 31 才启用 gzip 自动封装（即 15 + 16）。这个 16 是 zlib 内部定义的 MAX_WBITS + 16 偏移量，不是随便加的。
错误示例：deflateInit2(&strm, level, Z_DEFLATED, 15, 8, Z_DEFAULT_STRATEGY) → 输出无 header；deflateInit2(&strm, level, Z_DEFLATED, 16, 8, ...) → 初始化失败（非法 windowBits）。
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 必须用
windowBits = 31（即15 + 16）才能让deflate自动写 gzip header/trailer - 若要兼容 zlib 1.2.4 以下版本，需检查
ZLIB_VERNUM >= 0x1240，旧版不支持该模式 - 即使启用了 gzip wrapper，仍需确保
strm.avail_in和strm.next_in正确更新，否则最后 1–2 字节可能丢失
内存压缩时务必用 deflate 循环调用，别指望一次搞定
zlib 的 deflate 是流式接口，输入缓冲区满或输出缓冲区满都会返回 Z_OK 并暂停。常见错误是只调用一次 deflate(&strm, Z_FINISH)，导致部分数据未压缩或 CRC 错误。
正确流程是：先喂数据（Z_NO_FLUSH），最后用 Z_FINISH 触发收尾，且每次调用后检查 strm.avail_out == 0 是否成立，成立则扩容输出 buffer 并重试。
- 输出 buffer 初始大小建议 ≥ 输入大小 × 1.01 + 20（预留 header/trailer）
- 循环中若
deflate返回Z_STREAM_END，说明完成；若返回Z_OK且strm.avail_in > 0，说明还有输入没吃掉，需继续喂 - 忘记在循环末尾调用
deflateEnd会导致内存泄漏，尤其在频繁压缩场景下明显
gzip CRC32 必须用 zlib 的 crc32，别用 std::hash 或自实现
gzip trailer 要求 CRC32 值是针对**原始未压缩数据**计算的，并且必须用与 zlib 完全一致的多项式（0xEDB88320）、初始值（0xFFFFFFFF）、异或终值（再异或 0xFFFFFFFF）。自己写的 CRC 函数哪怕逻辑正确，字节序或初始化不同也会导致 gunzip: invalid compressed data--crc error。
更隐蔽的问题：如果压缩过程中分块调用 deflate，必须在第一次调用前用 crc32(0, nullptr, 0) 初始化，之后每块数据都用上一次返回值作为 crc 参数传入 crc32(crc, buf, len)。
- 最终 trailer 中的 CRC32 字段是小端序 4 字节，需用
memcpy(&trailer[0], &crc, 4)拷贝，不能用htonl - uncompressed size 字段也是小端序 4 字节，值为原始数据长度 mod 2^32（zlib 不校验是否溢出）
- 若原始数据为空（0 字节），header 中的
mtime建议设为 0，避免某些老旧工具解析异常
