zstd.newwriter不能传nil，必须绑定io.writer才能复用；正确做法是用reset复用实例，避免频繁new导致gc压力，且close必须调用并检查error，否则解压报checksum mismatch。
zstd.NewWriter 不能直接传 nil，必须绑定 io.Writer 才能复用
很多人一上来就写 zstd.NewWriter(nil)，以为这样能拿到可复用的 encoder 实例——实际会 panic：nil writer 不被允许。zstd 的 encoder 必须关联一个具体的 io.Writer 才能工作，哪怕只是临时的 bytes.Buffer 或 io.Discard。
正确做法是用 encoder.Reset(w io.Writer) 替代反复 New。Reset 会清空内部状态、重置 CRC、复用哈希表和窗口缓冲，避免每次新建带来的内存分配和 GC 压力。
- 别在循环里写
zstd.NewWriter(&buf)—— 每次都 new，GC 频繁，CPU 热点集中在内存分配 - 用
sync.Pool缓存*zstd.Encoder，New时传io.Discard占位，Get后调用Reset绑定真实目标 - 如果目标是字符串压缩（非文件），输出到
bytes.Buffer最自然；但注意别让 buffer 一直 grow，可提前Grow(4096)减少扩容次数
流式压缩字符串时，Write + Close 顺序不能错，否则丢失校验帧
zstd.Encoder 的 Close 不只是 flush，它还会写入 final frame 和 checksum。跳过 Close 或忽略其 error，解压端大概率报 zstd: checksum mismatch，且无法定位哪块出错。
典型错误是只 Write 不 Close，或者 Close 后没检查 error 就直接取 Buffer.Bytes()。尤其在并发场景下，多个 goroutine 共享同一 encoder 实例时，Close 调用时机更需严格控制。
- 每个压缩单元（如一个字符串）必须独立完成：
enc.Write(data)→enc.Close()→ 检查 error - Close 返回非 nil error 时，
Buffer.Bytes()可能是不完整或损坏的数据，不可用 - 若需连续压缩多个字符串到同一 buffer，不要复用 encoder，改用
zstd.Encoder.Append（需 v1.5+）或手动拼接 frame
压缩级别选 SpeedDefault 还是 SpeedFastest？看数据特征和延迟要求
对大文本（如日志、JSON、CSV），zstd.SpeedFastest（-5 级）不是万能加速键。它强制启用哈希表加速匹配，但小块数据（
实测显示：100KB+ 文本块用 zstd.SpeedDefault（1 级）比 -5 级快 1.3 倍，压缩率仅低 2.7%；而 10KB 以下短文本，-5 级才真正体现优势。
- 默认推荐
zstd.WithEncoderLevel(zstd.SpeedDefault)，平衡速度与压缩率 - 明确要求 sub-ms 延迟（如 gRPC payload）且文本普遍 SpeedFastest
- 务必加
zstd.WithEncoderCRC(true)，避免网络传输丢帧导致静默解压失败
并发压缩多个字符串时，WaitGroup + channel 容易卡死或资源争抢
常见模式是起 N 个 goroutine，每个调 compressString(s)，然后 WaitGroup.Wait()。问题在于：所有 goroutine 同时触发 I/O（buffer 写入）、CPU（zstd 压缩）和内存（buffer grow），硬盘随机读、CPU 核心锁竞争、GC 抖动全来了，实际吞吐可能比单协程还低。
真正高吞吐的做法是控制并发度 + 隔离阶段：读（I/O bound）、压（CPU bound）、写（I/O bound）三阶段用 channel 流水线串接，每阶段独立控制 worker 数量。
- 读阶段用 1–2 个 goroutine 顺序读原始字符串（避免磁盘寻道）
- 压阶段用
runtime.NumCPU()个 goroutine，每个独占 encoder 实例 - 写阶段用 1 个 goroutine 串行收集结果，避免 buffer 竞态
- 别用无缓冲 channel 传
[]byte，改传指针或预分配 slice，防止底层数组被意外复用
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
