本文介绍在 Go 应用中对未压缩的 http.Response.Body 进行流式 Gzip 压缩的方法，重点解决 io.ReadCloser 与 gzip.Writer 的桥接问题，并提供安全、高效、内存友好的实现方案。
本文介绍在 go 应用中对未压缩的 `http.response.body` 进行流式 gzip 压缩的方法，重点解决 `io.readcloser` 与 `gzip.writer` 的桥接问题，并提供安全、高效、内存友好的实现方案。
在构建缓存代理类服务（如 Redis 缓存响应）时，常需对原始 HTTP 响应体进行压缩后再持久化，以节省存储空间并提升后续传输效率。但 http.Response.Body 是一个 io.ReadCloser，而 gzip.Writer 要求写入目标为 io.Writer——二者接口方向相反，不能直接对接。关键在于：我们不是要“把 gzip 写入 body”，而是要“把 body 流式读取并写入 gzip 编码器”，最终获取压缩后的字节切片。
以下是一个简洁、健壮的实现：
import (
"bytes"
"compress/gzip"
"io"
"net/http"
)
func compressResponseBody(r *http.Response) ([]byte, error) {
// 使用 bytes.Buffer 作为内存中的可写目标
var buf bytes.Buffer
// 创建 gzip.Writer，包装 buffer
gz := gzip.NewWriter(&buf)
// 将响应体（ReadCloser）流式拷贝到 gzip.Writer
// io.Copy 自动处理读写循环和缓冲，高效且低内存占用
_, err := io.Copy(gz, r.Body)
if err != nil {
return nil, err
}
// 必须显式 Close()，否则 gzip 头尾元数据（如 CRC、ISIZE）不会写入
if err := gz.Close(); err != nil {
return nil, err
}
// 返回压缩后的完整字节数据
return buf.Bytes(), nil
}✅ 关键要点说明：
- io.Copy(gz, r.Body) 是核心——它将 r.Body 的全部内容按需读取，并实时送入 gz 进行压缩，全程无全量内存加载（除非 buf 动态扩容，但仍是可控的）；
- gz.Close() 不可省略：Gzip 格式要求在流末尾写入校验和（CRC32）和原始未压缩长度（ISIZE），Close() 才会刷新并写入这些元数据，否则解压端将报错（如 gzip: invalid checksum）；
- r.Body 在拷贝后仍处于 EOF 状态，若需复用（例如记录日志或二次处理），应在调用前用 io.NopCloser(io.MultiReader(...)) 或 ioutil.ReadAll + bytes.NewReader 重构，但本场景中通常只需单次消费；
- 若后续需写入 Redis Hash（如 HSET cache:key body
），该函数返回的 []byte 可直接序列化存储，无需 Base64 编码（Redis 对二进制安全）。
⚠️ 注意事项：
- 此函数仅适用于已确认未压缩的响应体（例如 Content-Encoding 为空或明确为 identity）。若原始响应已是 gzip，重复压缩不仅无效，还可能因损坏原始流导致错误；建议前置检查 r.Header.Get("Content-Encoding")；
- 如需更高性能或更大响应（如 >10MB），应避免 bytes.Buffer 全内存驻留，改用 io.Pipe 配合 io.Copy 直接写入 Redis writer（如 redis.Conn.Write），实现真正零拷贝流式压缩入库；
- 生产环境建议添加超时控制与大小限制（如 io.LimitReader(r.Body, maxBodySize)），防止恶意大响应耗尽内存。
综上，通过 io.Copy 桥接 ReadCloser 与 gzip.Writer，辅以正确的生命周期管理（Close），即可在 Go 中实现轻量、可靠、符合标准的响应体压缩逻辑——既保持流式处理优势，又满足缓存层对紧凑二进制数据的需求。
