Go默认不压缩HTTP请求体，必须手动用gzip.Writer压缩原始数据并显式设置Content-Encoding: gzip头，否则服务端按gzip解析明文会报400或invalid header；gz.Close()不可省略，否则尾部CRC32和ISIZE缺失导致解压失败。
Go 默认不压缩 HTTP 请求体，必须手动用 gzip.Writer 压缩原始数据，并显式设置 Content-Encoding: gzip 头；否则服务端收到的是明文却按 gzip 解析，直接报错。
客户端发请求前必须先压缩再设头
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() 就以为万事大吉。
