Golang 中如何高效实现HTTP请求的压缩与解压缩功能？

本文共计941个文字，预计阅读时间需要4分钟。

使用Go语言发送HTTP请求并压缩请求体，可以直接使用`gzip.Writer`来压缩原始数据。以下是实现步骤的简要说明：

客户端发请求前必须先压缩再设头

Go 的 http.Client 不会读你写的 Content-Encoding 头然后自动压缩 —— 它只原样转发你塞进 req.Body 的字节流。常见错误是只加头不压缩，导致服务端解压失败，返回 400 Bad Request 或 gzip: invalid header。

• 先用 bytes.Buffer + gzip.NewWriter 压缩原始 payload（比如 JSON 字节）
• 调用 gz.Close() —— 这步不可省，否则尾部 CRC32 和 ISIZE 缺失，服务端解压必崩
• 再用 bytes.NewReader(buf.Bytes()) 构造新 req.Body
• req.Header.Set("Content-Encoding", "gzip") 必须写，且不能拼错
• req.Header.Set("Content-Length", strconv.Itoa(buf.Len())) 必须设为压缩后长度，不是原始长度

为什么 gz.Close() 不能用 gz.Flush() 替代

gzip.Writer 是缓冲型写入器：Write() 只推进压缩管道，Flush() 只刷出当前压缩块，但 Gzip 格式强制要求末尾 8 字节（CRC32 + ISIZE）—— 这些只在 Close() 时写入。漏掉它，Linux 下 zcat、Go 的 gzip.NewReader 全都会拒绝该流。

• 现象：服务端调 gzip.NewReader(r.Body) panic 报 gzip: invalid checksum 或 unexpected EOF
• 缓存到 Redis 或写磁盘时也一样：存进去的不是完整 gzip 流，取出来根本解不开
• 务必配对 defer gz.Close()，并检查其 error 返回（比如磁盘满、网络断连）

服务端接收压缩请求时的解压要点

服务端不会自动解压请求体，需手动判断 Content-Encoding 并包装 r.Body。注意它和响应自动解压完全不同 —— Go 的 http.Transport 只对响应体自动解压，对请求体完全不管。

立即学习“go语言免费学习笔记（深入）”；

• 只处理 r.Header.Get("Content-Encoding") == "gzip"，忽略 deflate 等其他编码（除非你额外支持）
• 别直接把 r.Body 传给 gzip.NewReader：先确认开头是 0x1f 0x8b（gzip magic bytes），防 HTTP 分块头或空格污染
• 解压后记得 defer reader.Close()，否则复用连接时底层状态混乱
• 建议统一用中间件封装，避免每个 handler 都重复写判断逻辑

大设备数据上报时的额外约束

IoT 场景下批量压缩上报，光压对还不行，得防弱网和平台限制：

• 单次压缩后体积超 1MB（解压后）？阿里云 IoT 等网关可能直接拒收，得拆分
• HTTP 客户端要显式调大 transport.MaxIdleConnsPerHost（比如设为 10），避免并发上报排队
• 设 transport.ResponseHeaderTimeout = 5 * time.Second，防 TLS 握手或首包延迟卡死
• 别用 strings.Builder 拼接再压 —— 大数据量易触发内存抖动；bytes.Buffer 预估容量后扩容更稳

最常被跳过的其实是 gz.Close() 的 error 检查，它不总为 nil；往文件或网络连接写时，磁盘满、连接中断都会在这里暴露，但多数人只写了 defer gz.Close() 就以为万事大吉。