自定义streambuf压缩写入的核心难点在于缓冲区管理与压缩器生命周期的耦合：zlib等压缩上下文必须在析构时正确deflateEnd，且需应对异常提前销毁导致的中间状态问题。
streambuf 自定义压缩写入的核心难点在哪
直接继承 std::streambuf 做压缩写入，不是“重写 sputn 就完事”——关键在于缓冲区管理与压缩器生命周期的耦合。zlib、lz4 或 zstd 的压缩上下文（如 z_stream）必须在 streambuf 析构时正确 deflateEnd，否则资源泄漏；而写入中途若流被提前销毁（比如异常退出或局部对象析构），压缩器可能处于中间状态，导致输出不完整或崩溃。
怎么安全地把 zlib 压缩塞进 streambuf
别在 streambuf 里直接调 deflate，先用双缓冲策略：一个输入缓冲区（接收 sputn 数据），一个压缩输出缓冲区（供 overflow/sync 刷出）。压缩只在缓冲满、sync() 被调用，或 overflow(EOF) 时触发。
-
setp指向输入缓冲区起始，pptr()管理已写入位置，每次sputn后检查是否溢出 - 压缩输出缓冲区用
std::vector<char>动态管理，避免栈溢出或固定大小限制 -
sync()必须 flush 输入缓冲区 + 触发一次Z_SYNC_FLUSH（非Z_FINISH），否则实时性失效 - 析构函数中判断
z_stream是否已初始化，只对zalloc != nullptr的实例调deflateEnd
为什么 std::ostream 构造后立刻 write 会丢数据
常见错误是构造 std::ostream 时传入自定义 streambuf*，但没调 std::ostream::rdbuf() 替换默认缓冲区，或者替换后没设 std::ios_base::unitbuf——导致数据仍被上层 ostream 缓冲，根本没进你的 streambuf。
- 务必用
os.rdbuf(my_buf_ptr)显式接管，不能只靠构造函数参数（某些标准库实现忽略它） - 加
os.setf(std::ios_base::unitbuf)强制每次<<后自动flush，否则依赖std::endl或手动flush() - 若用
write()接口，注意它绕过格式化层，但依然走rdbuf()->sputn()，所以缓冲逻辑必须完备
gzip header 和 trailer 怎么处理才合规
zlib 的 deflate 只做纯压缩，不带 gzip 头/尾；要生成标准 gzip 流，得自己写 10 字节头（包括 magic、OS、mtime）和 8 字节尾（crc32 + uncompressed size），且头必须在第一次 deflate 前写入底层目标流（如 std::ofstream）。
立即学习“C++免费学习笔记（深入）”；
- 头写入时机：在
streambuf首次sync()或overflow(EOF)前，调用一次底层流的write() - 尾写入时机：仅在
~your_streambuf()中，且仅当deflate(..., Z_FINISH)成功返回后才写 crc+size - 别用
gzopen/gzwrite混搭——它们有自己的缓冲和FILE*层，和streambuf无法协同
实时压缩写入最难缠的其实是 flush 语义和错误传播：zlib 返回 Z_BUF_ERROR 时该重试还是报错？streambuf 没法 throw 异常，只能靠 sputn 返回值和 failbit 通知上层——这点很容易被忽略，结果压缩失败却静默吞掉错误。
