启用 WebSocket 压缩只需在 websocket.Upgrader 中设置 EnableCompression: true，底层自动协商 permessage-deflate 扩展，仅对 ≥1024 字节的 TextMessage/BinaryMessage 生效，不可调压缩级别。
Go 的 gorilla/websocket 怎么开压缩？两行配置就生效
启用压缩不靠手动压数据，而是让 WebSocket 协议层自动协商和处理 —— gorilla/websocket 的 EnableCompression 就是干这个的。它底层调用的是标准 permessage-deflate 扩展，握手时通过 Sec-WebSocket-Extensions 头自动协商，无需你碰 zlib 或 deflate 参数。
- 必须在
websocket.Upgrader实例上设EnableCompression: true，仅此一项即可触发协商 - 客户端也得支持该扩展（现代浏览器、
ws、gorilla/websocket客户端默认都支持） - 压缩只作用于
TextMessage和BinaryMessage帧，但对BinaryMessage是否压缩取决于服务端实现；gorilla默认只对文本帧启用 - 别试图自己用
flate.Writer包一层再发 —— 会和协议层压缩叠加，导致客户端解压失败或乱码
为什么开了 EnableCompression 却没看到效果？
常见假阴性：你以为没压，其实是数据太小被跳过了。WebSocket 压缩有内置阈值，默认 1024 字节以下不压缩（避免小包压缩反而膨胀），这行为不可配置 —— gorilla 没暴露 threshold 选项。
- 测试时用 >2KB 的 JSON（比如含 100 条日志的数组），再抓包看
Content-Encoding: deflate是否出现 - Wireshark 或 Chrome DevTools 的 Network → WS → Frames 标签页里，看消息 size 列是否明显小于原始 payload
- 服务端日志加一句
log.Printf("msg len: %d, compressed: %t", len(msg), conn.IsCompressed())（注意：IsCompressed()是连接级状态，不是每条消息独立判断） - 如果客户端是自研的（比如嵌入式设备），确认它真发了
permessage-deflate到Sec-WebSocket-Extensions，否则服务端不会回协商参数
compress/flate 级别能调吗？别白费劲
不能。gorilla 的 EnableCompression 不接受 level、memLevel 等参数 —— 它复用 Go 标准库 flate.NewWriter 的默认配置（level=6），且不提供覆盖入口。强行想调？只能 fork 修改源码，代价远大于收益。
- 小数据（flate.NewWriter 对短输入几乎不压缩，甚至可能膨胀
- 大数据下 level=6 和 level=9 的带宽节省差异通常
- 真有极端压缩需求（如 IoT 上行极窄带宽），应换算法：用
zstd或snappy自行封装成二进制帧，绕过 permessage-deflate，但要承担客户端适配成本
压缩后 CPU 高、延迟升了？先看是不是误伤了关键路径
压缩本身是同步阻塞操作，发生在 WriteMessage 调用内部。如果你在 handler 里边收边压边发（比如 echo 服务），那单连接吞吐会受限；但更常见的是——你在压缩之外做了重活。
立即学习“go语言免费学习笔记（深入）”；
- 避免在
WriteMessage前拼接超大字符串（如strings.Repeat("a", 1e6)），内存分配 + 压缩双重压力 - 别在 WebSocket handler 里调数据库、HTTP 请求或复杂 JSON marshal —— 这些耗时远高于压缩，压缩只是背锅侠
- 广播场景下，用
conn.WriteMessage逐个推不如用conn.SetWriteDeadline+ 复用[]byte缓冲区，减少 GC 压力 - 压测时观察
go tool pprof的 CPU profile，确认热点真在flate.compress，而不是json.marshal或锁竞争
