Go标准库无gzip.CompressString，需用bytes.Buffer+gzip.Writer压缩字符串：字符串→[]byte→gzip.Writer→Buffer→[]byte，必须调w.Close()；解压用bytes.NewReader+gzip.Reader，同样需r.Close()。
gzip.CompressString 不存在，得自己封装 gzip.Writer 和 gzip.Reader
Go 标准库没有提供开箱即用的字符串压缩函数，compress/gzip 操作的是 io.Writer 和 io.Reader，不是字符串。直接调 gzip.NewWriter 写入字符串前，必须先把字符串转成 []byte，再通过 bytes.Buffer 中转——这是最常用也最稳妥的方式。
常见错误是试图把字符串直接传给 gzip.Writer，结果编译不报错但运行时 panic（因为没处理底层 writer 的错误），或者解压后得到空字符串（忘了 Flush() 和 Close()）。
- 必须调用
w.Close()，否则压缩流不完整，解压会失败或丢数据 -
bytes.Buffer是线程不安全的，多 goroutine 并发压缩需各自 new 一个 - 压缩空字符串是合法的，但输出长度不为 0（Gzip header 至少 10+ 字节）
压缩字符串：用 bytes.Buffer + gzip.Writer 写入 []byte
核心流程：字符串 → []byte → gzip.Writer → bytes.Buffer → []byte（压缩后）→ 可选转回 string。注意别漏掉 w.Close()，它会刷新缓冲并写入 Gzip trailer。
func GzipString(s string) ([]byte, error) {
buf := &bytes.Buffer{}
gw := gzip.NewWriter(buf)
_, err := gw.Write([]byte(s))
if err != nil {
return nil, err
}
if err = gw.Close(); err != nil { // 关键！不 Close 就没压缩完
return nil, err
}
return buf.Bytes(), nil
}
如果后续要 base64 编码传输，可直接对返回的 []byte 调 base64.StdEncoding.EncodeToString；不要对原始字符串做 base64 再压缩，那会降低压缩率。
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
立即学习“go语言免费学习笔记（深入）”；
解压缩字符串：用 bytes.NewReader + gzip.Reader 读出 []byte
解压时同样不能直接操作 string，必须把压缩后的 []byte 包装成 io.Reader。用 bytes.NewReader 最轻量，避免额外内存拷贝。解压失败常见于输入非 gzip 流（比如传了明文）、或压缩数据被截断（比如网络传输丢包、base64 解码错误）。
func GunzipBytes(data []byte) (string, error) {
r, err := gzip.NewReader(bytes.NewReader(data))
if err != nil {
return "", err // 比如 "invalid gzip header"
}
defer r.Close()
out, err := io.ReadAll(r)
if err != nil {
return "", err
}
return string(out), nil
}
- 务必
defer r.Close()，否则可能泄露文件描述符（虽然内存里没 fd，但 gzip.Reader 内部有状态） - 如果输入是 base64 编码过的，先用
base64.StdEncoding.DecodeString得到[]byte，再传给GunzipBytes - 解压超大字符串（>100MB）建议用流式处理（
io.Copy到目标 writer），避免一次性加载进内存
压缩率低或解压失败？检查输入是否已含二进制/不可见字符
Gzip 对纯 ASCII 文本压缩效果好，但对短字符串（"invalid gzip header" 或 "unexpected EOF"，说明输入根本不是合法 gzip 流。
- 用
file -i your_data.bin或hexdump -C data.bin | head看前 10 字节：合法 gzip 以1f 8b开头 - 如果压缩后长度 ≥ 原长度，大概率是内容本身熵太高，或字符串太短（Gzip header 开销固定约 18 字节）
- HTTP 场景下，别在已经启用
Content-Encoding: gzip的响应体上再手动 gzip，会导致双重压缩失败
实际业务中，压缩前最好加个长度判断：小于 200 字节的字符串，跳过压缩反而更省 CPU 和带宽。
