gzip.writer 直接写日志会卡住或丢数据，因其默认缓冲且不显式 flush() 或 close() 时数据滞留内存；必须用 gzip.newwriterlevel 配合 bufio.writer，并在每次 write 后调用 gz.flush() 确保压缩帧即时推送。
为什么 gzip.Writer 直接写日志会卡住或丢数据
因为 gzip.Writer 默认带缓冲，不显式 Flush() 或 Close()，数据就卡在内存里出不去；而日志是持续追加的，你不能等程序退出才关流。常见现象是客户端收不到实时日志、首条日志延迟数秒、甚至连接超时断开。
关键点不是“能不能压”，而是“压完立刻推出去”。必须绕过默认缓冲策略，用 bufio.Writer 控制底层写入节奏，同时避免频繁小包触发 TCP Nagle 算法。
- 别用
gzip.NewWriter(conn)直接包装网络连接 —— 它的缓冲不可控，且Write()不保证落网 - 用
gzip.NewWriterLevel(bufio.Writer, gzip.BestSpeed)，压缩级别选gzip.BestSpeed（值 1），兼顾 CPU 和实时性 - 每次写完日志行后调用
gzWriter.Flush()，不是bufio.Writer.Flush()—— 前者会把压缩帧刷到底层bufio.Writer，后者只刷未压缩数据
如何构造可复用的带压缩的 io.Writer 接口
日志库（如 log/slog 或 zap）通常只接受 io.Writer。你需要封装一个类型，把 gzip.Writer + bufio.Writer + 底层连接串起来，并确保 Write() 调用能触发即时压缩推送。
核心结构体要嵌入 io.WriteCloser，但重写 Write(p []byte) (int, error)：先写进 gzip.Writer，再强制 Flush()，最后返回实际字节数。注意不要在 Write() 里调用 Close()。
type GzipWriter struct {
gz *gzip.Writer
bw *bufio.Writer
w io.Writer
}
func (g *GzipWriter) Write(p []byte) (int, error) {
n, err := g.gz.Write(p)
if err != nil {
return n, err
}
if err = g.gz.Flush(); err != nil { // 关键：立刻冲出压缩帧
return n, err
}
return n, nil
}
func (g *GzipWriter) Close() error {
g.gz.Close() // 先关 gzip，生成 EOF 标记
return g.bw.Flush() // 再刷干净 bufio 缓冲
}
net.Conn 作为底层时要注意 TCP 拆包和粘包
Gzip 流本身是无边界的二进制流，TCP 也是字节流 —— 服务端发 10 行压缩日志，客户端 Read() 可能一次拿到 3 行、也可能分 5 次收到。如果客户端直接用 gzip.NewReader(conn)，第一次 Read() 就可能卡住，因为没收到完整 gzip header 或等不到后续字节。
解决方案不是改服务端，而是客户端必须用带缓冲的读取逻辑：先读够至少 10 字节（gzip magic + flags），再用 gzip.NewReader(io.MultiReader(headerBuf, conn))；或者更稳妥地，在服务端每条日志后加换行符（\n），客户端按行解压（需自定义 reader 解析边界）。
- 服务端不要依赖“一次
Write()对应一次 TCP 包” —— 启用SetNoDelay(true)关闭 Nagle 算法 - 客户端解压前，建议用
bufio.NewReader(conn)包一层，避免因小包频繁系统调用 - 若传输中断，gzip 流无法恢复 —— 日志场景建议每 N 条或每秒强制切一个新 gzip stream（加 header），而非长连单流
性能陷阱：CPU 占用高但吞吐没提升？检查 gzip.BestCompression
用 gzip.BestCompression（值 9）压日志纯属浪费：日志文本重复模式少、熵高，压缩率提升不足 5%，但 CPU 时间翻 3 倍以上，反而拖慢写入，导致日志堆积、goroutine 阻塞。
实测表明，对典型 JSON 或 key=value 日志行，gzip.BestSpeed（1）和 gzip.DefaultCompression（6）的压缩比差距小于 8%，但 P99 写延迟降低 40%+。
- 线上环境一律用
gzip.BestSpeed，除非你明确需要存档级压缩且 CPU 富余 - 避免在日志格式中混入随机字符串（如 UUID、毫秒时间戳）—— 它们破坏 gzip 的字典匹配，让压缩几乎失效
- 如果日志量极大（>100MB/s），考虑用
zstd替代 gzip（需引入github.com/klauspost/compress/zstd），它有更好的流式控制和多线程支持
Flush()、误用缓冲层级、忽略 TCP 流特性，三者任一都会让整个链路变成黑盒。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
