Go语言需手动控制消息压缩：gorilla/websocket的EnableCompression仅协商permessage-deflate，客户端须带Sec-WebSocket-Extensions头，仅≥1024字节的Text/Binary帧触发；net/rpc需包装conn并确保gzip作用于完整length-prefix消息且每次调用后Flush。
Go 语言本身不内置消息压缩传输能力，必须通过协议层或连接层显式介入。是否启用压缩、用在哪一层、对什么数据生效——这些全由你控制，也全是你容易出错的地方。
gorilla/websocket 的 EnableCompression 怎么用才生效
它只在 WebSocket 协议协商阶段起作用，不是“开了就压一切”。关键点是：
-
EnableCompression: true必须设在websocket.Upgrader实例上，且要在调用Upgrade()之前 - 客户端必须在握手请求头里带上
Sec-WebSocket-Extensions: permessage-deflate；现代浏览器和gorilla/websocket客户端默认带，但自研客户端（如嵌入式设备）常漏掉 - 压缩仅对
TextMessage和BinaryMessage帧触发，但gorilla默认只对文本帧启用；若要压二进制帧，需额外设置Upgrader.CheckOrigin或自定义websocket.Conn行为 - 小于 1024 字节的消息会被跳过压缩——这是硬编码阈值，无法调整。测试时务必用 >2KB 的 JSON 或日志数组
- 别手动套
flate.Writer：协议层压缩 + 应用层再压 = 客户端解压失败或乱码
net/rpc 怎么加 gzip 压缩而不崩
标准 net/rpc 不支持压缩，强行包装 net.Conn 是最直接方式，但极易因 flush、长度字段、小包膨胀等问题失败：
- 服务端用
gzip.NewReader(conn)包装读取器后传给rpc.ServeConn；客户端用gzip.NewWriter(conn)包装写入器，再传给rpc.NewClient -
gzip.Writer必须在每次 RPC 调用后调用Flush()，否则数据卡在缓冲区，服务端收不到完整消息 - RPC 消息是 length-prefix + payload 格式，压缩必须作用于整个消息体（含长度字段之后的所有字节），不能只压 payload，否则长度字段失效导致粘包或 EOF
- 小消息（
- 两端必须使用完全一致的 gzip 级别（如都用
gzip.BestSpeed），否则解压失败静默丢包
gRPC 的 gzip 压缩为什么客户端收不到解压后数据
常见原因是配置不对称或阈值拦截，不是算法问题：
立即学习“go语言免费学习笔记（深入）”；
- 服务端必须注册编码器：
grpc.RegisterCodec(codec.NewGZIPCodec())；客户端必须同时设grpc.WithCompressor和grpc.WithDecompressor，缺一不可 - 默认压缩阈值是 1KB（
grpc.DefaultCompressorThreshold），空消息（如google.protobuf.Empty）或短请求必然跳过 - 确认 WireShark 或 gRPC 日志里请求 Header 是否含
grpc-encoding: gzip；没有说明WithCompressor没生效，或被后续 Dial 选项覆盖 -
MaxRecvMsgSize和MaxSendMsgSize要按原始未压缩大小设置，不能按压缩后大小调小，否则解压前缓冲区溢出 - gRPC 只支持
gzip和snappy（后者需额外导入google.golang.org/grpc/encoding/snappy），zstd 等需自行实现encoding.Compressor接口
压缩策略选型：gzip / zstd / snappy 到底怎么挑
不是越高压越好，得看场景、客户端支持和 CPU 预算：
- HTTP 场景只能用
gzip或br：浏览器只认这两个Content-Encoding，传zstd头会被忽略 - 内网 RPC 或私有协议可上
zstd：实测 50–500KB 文本，zstd.SpeedFastest比gzip.BestSpeed快 2.3 倍、体积小 8%；但启用SpeedBestCompression后 CPU 翻倍，体积只再降 1.2%，不划算 -
snappy解压极快，适合实时日志推送这类“宁可多发流量也要低延迟”的场景，但压缩率差，50KB 日志压完可能只少 5% - 永远检查输入长度：200 字节以下的 JSON，gzip 压完反而大 18 字节（header 开销）；1MB+ 的 base64 图片，压缩率常低于 2%，纯属白耗 CPU
- 别把
gzip.NewWriter当策略返回——调用方忘了Close()就会丢数据；正确做法是把 new/write/close 全包进Compress()方法体内
压缩不是开关，是精细调控：协议层、连接层、消息层各有一套规则，跨层混用大概率失败；阈值、级别、格式兼容性，任何一个点没对齐，就会出现“开了却没压”或“压了却解不开”的静默故障。
