strings.NewReader 不能用于压缩，因为它仅提供一次性只读流，不支持压缩器所需的回退、多次遍历或流式压入；gzip 等库需完整 header 初始化，直接传入会因无数据或立即 EOF 导致“invalid header” panic。
为什么不能直接用 strings.NewReader 做压缩？
因为 strings.NewReader 返回的是 *strings.Reader，它实现的是 io.Reader，但不支持 io.ReaderAt 或 io.Seeker —— 而多数压缩库（如 gzip、zlib）内部需要读取时能回退或多次遍历，或者要求底层 reader 支持按需拉取（比如 flate.Writer 期望写入流，而非预缓冲的只读快照）。直接传字符串 reader 给 gzip.NewReader 会 panic：gzip: invalid header，本质是没数据可读，或读完就 EOF，压缩器无法完成初始化。
正确做法：用 bytes.Buffer + gzip.Writer 构建可压缩的字节流
自定义 Reader 的目标不是“让字符串变压缩 Reader”，而是“把字符串内容实时压缩，并暴露为 io.Reader”。最稳的方式是先压缩进 buffer，再用 bytes.NewReader 包装结果：
- 先创建
bytes.Buffer，传给gzip.NewWriter - 写入原始字符串（
w.Write([]byte("hello"))），然后调用w.Close()触发 flush 和 trailer 写入 - 用
bytes.NewReader(buf.Bytes())得到可重复读的压缩后io.Reader
示例：
src := "hello world" var buf bytes.Buffer w := gzip.NewWriter(&buf) w.Write([]byte(src)) w.Close() // 必须调用，否则压缩头/尾不完整 reader := bytes.NewReader(buf.Bytes()) // 这才是可用的压缩 Reader
如果真要“流式”压缩 Reader（边读边压），得自己实现 io.Reader
场景：原始数据来自网络或大文件，不想全量加载到内存。这时不能依赖 bytes.Buffer，而要封装一个“读取原始数据 → 压缩 → 输出”的 reader。但注意：gzip.Writer 不是线程安全的，且不能复用；每次读操作都需新建压缩器会导致开销爆炸。更现实的做法是组合 io.Pipe：
立即学习“go语言免费学习笔记（深入）”；
- 启动 goroutine，在 pipe write end 写入原始数据并压缩
- pipe read end 就是你要的
io.Reader - 务必处理 goroutine panic 和 close 同步，否则 reader 可能卡住或返回
io.ErrClosed
关键点：io.Pipe 的 write side 必须在 goroutine 中调用 w.Close()，否则 reader 会永远阻塞在 EOF 等待。
容易踩的坑：gzip header、level、multistream
gzip.NewReader 默认校验 header，若你用 flate.Writer（zlib）压缩，就不能用 gzip.NewReader 解；反之亦然。常见错误：
- 用
zlib.NewWriter压缩，却用gzip.NewReader读 →invalid header - 压缩时设了
gzip.BestSpeed，但解压端没指定对应 flavor → 实际不影响，但 level 仅影响压缩阶段 - 多段 gzip 流（
gzip.WithMultistream(true)）默认关闭，若源数据是拼接的多个 gzip 块，解压时必须显式启用
压缩参数要和解压端对齐，尤其 Header 和 Extra 字段是否写入 —— 这些细节在跨语言交互时特别容易出问题。
真正麻烦的不是怎么写 Reader，而是压缩格式协商和边界控制。比如 HTTP 响应里写 Content-Encoding: gzip，那你就必须输出标准 gzip 格式（含 magic header + footer），不能只用 flate。
