gzip.Writer写入后必须调用Close()才能写出完整压缩流，否则缺少CRC、ISIZE等尾部校验信息，导致解压失败或数据不完整；Flush()仅刷新压缩块，不写尾部，不可替代Close()。
gzip.CompressWriter 写入后必须调用 Close 才能完成压缩
很多初学者发现用 gzip.NewWriter 压缩字符串后，得到的字节切片长度异常小，甚至和原文一样长——根本没压缩。问题通常出在忘了调用 w.Close()。gzip.Writer 是缓冲写入，数据先写入内部 buffer，只有调用 Close() 或 Flush() 才真正触发压缩并写入底层 io.Writer。直接读取底层 bytes.Buffer 的内容而未 close，拿到的只是未压缩的原始输入。
正确做法：
buf := &bytes.Buffer{}
gz := gzip.NewWriter(buf)
gz.Write([]byte("hello world"))
gz.Close() // 必须！否则 buf.Bytes() 为空或不完整
compressed := buf.Bytes()
-
Flush()可强制刷新当前 buffer，但不会写入 gzip 尾部校验信息（如 CRC32、ISIZE），解压时可能失败；Close()才会写入完整格式 - 如果后续还要复用
gzip.Writer，不能重复Close()，否则 panic：close of closed channel - 别用
defer gz.Close()在函数开头就 defer，除非确定所有写操作已完成——defer 在函数 return 后才执行，中间 error 早于写入就可能漏压缩
解压时 io.ReadFull 报错 “unexpected EOF” 怎么办
常见错误是把未完整写入的 gzip 数据（比如忘了 Close()）传给解压逻辑，或者从网络/文件读取时只读了一部分。gzip 格式要求末尾有 8 字节 trailer（CRC32 + uncompressed size），缺了就报 unexpected EOF 或 gzip: invalid header。
验证和修复方式：
立即学习“go语言免费学习笔记（深入）”；
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
- 先检查输入字节切片长度是否 ≥ 10（最小合法 gzip 流：10 字节 header + 8 字节 trailer = 至少 18 字节？不对——实际最小 gzip 流可短至 18 字节，但常见空字符串压缩后是 20 字节左右；更稳妥的是用
gzip.NewReader包装后调Read，它内部会校验 - 解压前用
bytes.NewReader(compressed)构造 reader，再传给gzip.NewReader()；不要手动切分或截断 - 如果数据来自 HTTP body 或 socket，确保读满整个响应体——用
io.ReadAll而非只读固定长度 - 错误示例：
io.ReadFull(gzReader, dst)对不定长解压结果强行读满会导致 panic；应改用io.Copy(&dstBuf, gzReader)或循环Read
compress/gzip 默认压缩级别影响性能与体积
gzip.NewWriter 使用默认级别（gzip.DefaultCompression，即 6），但你可以用 gzip.NewWriterLevel 指定 0（no compression）到 9（max compression）。级别越高，CPU 和时间开销越大，压缩率提升却边际递减。
典型场景建议：
- 日志上传、API 响应体压缩：用
gzip.BestSpeed（1）或gzip.DefaultCompression（6）平衡速度与体积 - 离线归档、配置下发：可尝试
gzip.BestCompression（9），但注意 Go 的 gzip 实现比 C 版本慢不少，9 级可能比 6 级慢 3–5 倍 - 级别为 0 时等价于透传，输出是带 gzip header/trailer 的原始数据，解压正常但无压缩效果
- 注意：
gzip.NewWriterLevel第二个参数非法（如 -1 或 10）会 panic，不是静默降级
字符串与 []byte 转换时的编码隐含假设
Go 中字符串本质是只读的 UTF-8 字节序列，string(bytes) 和 []byte(str) 转换不涉及编码转换——它们共享底层字节。但如果你的原始“字符串”其实是 GBK、Shift-JIS 等非 UTF-8 编码，直接转成 []byte 再压缩，解压后仍需按原编码解释，Go 标准库不处理编码转换。
这意味着：
- 压缩/解压过程本身不关心文本编码，只操作字节流
- 如果业务要求解压后得到正确显示的中文，确保原始字符串已经是 UTF-8（例如从 JSON、HTTP header、标准库读取的文本基本都是 UTF-8）
- 若必须处理 GBK 字符串，先用
golang.org/x/text/encoding/compat或github.com/axgle/mahonia转 UTF-8，再压缩；解压后再转回 GBK —— 压缩层不负责这个 - 误把乱码字符串（如 UTF-8 字节当 GBK 解）去压缩，解压出来还是乱码，和 gzip 无关
gzip 本身没有 magic number 校验之外的文本语义，它只认字节。容易被忽略的是：你认为的“字符串压缩”，实际全是字节流操作，编码一致性得自己兜底。
