Go处理大规模数据压缩传输需采用流式分块、并发协作与接口适配策略，避免OOM和校验错误，合理设置缓冲区并注意字节切片复制。
Go 语言处理大规模数据压缩与传输，核心不是“能不能压”，而是“怎么压不卡死、不爆内存、不丢错误”。关键在于放弃一次性加载+全量压缩的思路，改用流式分块 + 并发协作 + 接口适配的组合策略。
避免 bytes.Buffer 累积全部压缩数据
常见错误是把 gzip.NewWriter 或 zlib.NewWriter 绑定到 bytes.Buffer，再等整个文件读完才取 buf.Bytes()。TB 级数据下，这直接 OOM。
- 真正该做的是：让压缩器写入一个能“边写边送”的目标，比如网络连接、文件句柄，或你自己实现的
io.Writer—— 比如封装了chan []byte的通道写入器 - 如果必须暂存压缩块（例如分片上传），则每次
Write后手动buf.Reset()，并确保Close()被调用，否则 gzip 尾部校验信息缺失，解压端会报invalid checksum -
gzip.Writer默认缓冲区约 4KB，对高吞吐场景偏小；可配合io.CopyBuffer使用自定义 buffer（如 1MB），减少系统调用次数
用 channel 实现压缩流的并发分发
当需要把压缩后的数据交给多个消费者（如上传到不同对象存储、写入多个分片文件），不能靠一个 chan []byte 直接广播——Go channel 不支持多读，且无背压控制。
- 正确做法是启动一个“压缩主协程”，它负责读源数据 → 压缩 → 发送到一个
chan BytesWithError（BytesWithError是含Data []byte和Err error的结构体） - 再启动 N 个消费协程，每个从同一 channel 读；但注意：channel 是 FIFO 共享队列，不是广播。若需广播，得用
sync.Map+ 每个消费者独立 channel，或用github.com/robfig/cron/v3类库的广播模式（非标准库） - 务必在发送前复制
[]byte：原始切片若来自bufio.Reader的内部缓冲区，重用后内容会被覆盖。应写成ch
gzip 与 zlib 在传输场景中的实际取舍
二者都基于 DEFLATE，但协议头和用途差异直接影响能否被接收方正确识别。
- HTTP 场景一律用
compress/gzip：客户端自动识别Content-Encoding: gzip头，并用标准库gzip.NewReader解压；zlib 输出无 magic header，浏览器或 nginx 会直接拒收 - TCP 自定义协议或 RPC 二进制流，优先选
compress/zlib：输出更紧凑（少 18 字节 header），且zlib.NewReader可跳过 header 校验（用zlib.NoHeader），适合嵌入式或低开销链路 - 别混用：用
gzip.NewWriter压缩的数据，不能用zlib.NewReader解；反之亦然。错误现象通常是zlib: invalid header或gzip: invalid checksum
压缩级别与 CPU/带宽的平衡点
设错级别不会导致失败，但会让传输时间或体积失控。
-
gzip.BestSpeed（值为 1）：适合实时日志推送、HTTP 流响应，压缩比低但 CPU 占用最小；实测比默认级快 2.3×，体积大 15–20% -
gzip.DefaultCompression（值为 -1）：通用推荐，平衡压缩比与耗时；90% 场景够用 -
gzip.BestCompression（值为 9）：只在归档冷数据时启用；压缩耗时可能是 level 1 的 8 倍以上，而体积仅再降 3–5% - 注意：
zlib包没有BestSpeed常量，需显式传1；且它的 level 9 比 gzip 的更激进，慎用
最易被忽略的一点：无论用哪种压缩器，Close() 必须被调用，且只能调用一次。漏掉它，尾部校验和不写入，接收方解压到末尾必然失败；重复调用则 panic。在 defer 中写 defer w.Close() 是安全底线，但若压缩逻辑跨 goroutine，就得用 channel + select 等方式同步通知关闭时机。
