流式压缩无法实时计算压缩比，因lz77窗口和huffman表需close()或flush()后才确定；正确做法是分段写入、显式flush()、累计原始与压缩字节数，且必须调用close()并检查error。
压缩比不能在流式写入中途计算
流式压缩（如 gzip.Writer 或 zlib.Writer）不提供“当前已压缩字节数”接口，因为压缩是状态依赖的：LZ77 滑动窗口和 Huffman 表构建必须等到 Close() 或 Flush() 才能确定最终编码。你在 Write() 过程中看到的 bytes.Buffer.Len() 是未完成的中间结果，可能被后续数据重写或补全，直接拿它算“实时压缩比”会严重失真。
正确做法：分段 + 显式 Flush + 累计统计
若你真需要近似累计压缩比（比如监控传输进度或做背压决策），唯一可靠路径是主动分段、强制刷新、分别记录原始与压缩长度：
- 把输入流按固定大小（如 8KB）切块，避免单块过大导致内存峰值
- 每块写入前记下
len(chunk)；写入后调用w.Flush()（不是Close()）确保该块压缩数据已落到底层bytes.Buffer - 用
buf.Len()减去上一次 flush 后的长度，得到该块压缩后字节数 - 维护两个累加器：
totalIn和totalOut，每次更新后算float64(totalOut) / float64(totalIn)
注意：Flush() 不等于 Close()——前者只刷出当前可用压缩数据，后者还会写 gzip trailer 和校验和，必须留到最后调用。
gzip vs zlib 的元信息开销会影响小块压缩比
gzip 格式头部 + trailer 固定约 20 字节，zlib 头部 + Adler32 校验和约 6 字节。如果你分块太小（比如 100 字节），这些头尾开销会让单块压缩比虚高甚至 >1.0（即变大）。实践中建议最小分块 ≥ 1KB，否则累计值毫无参考价值。
- HTTP 响应流：别分段，等整个响应体写完再算最终压缩比
- 日志管道：用 4–8KB 分块，配合
bufio.Reader提升读取效率 - 千万别用
chan []byte边压边发再统计——channel 本身无序，且无法保证 flush 时机
最终压缩比必须以 Close() 后的总长度为准
所有流式压缩器（gzip.Writer、zlib.Writer、flate.Writer）都要求显式调用 Close() 才会输出完整格式数据。漏掉这步，bytes.Buffer.Bytes() 返回的可能是截断内容，压缩比计算结果必然偏低。
最常被忽略的一点：Close() 可能返回 error（比如底层 writer 写失败），这个 error 必须检查——否则你以为压完了，其实最后几 KB 根本没写出。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
