gorilla/websocket需显式启用且满足三条件才压缩：服务端设enablecompression、客户端发permessage-deflate头、连接后调conn.enablewritecompression(true)；≤1024字节消息强制跳过压缩，不可配置。
Go 语言的 gorilla/websocket 不会自动压缩消息，必须显式启用且满足一整套协作条件才能生效——漏掉任一环节，压缩就静默失效。
EnableCompression 只是协商意愿，不是开关
EnableCompression: true 设在 websocket.Upgrader 上，仅表示“服务端愿意接受 permessage-deflate”，不等于压缩已启用。它只影响握手响应头是否包含 Sec-WebSocket-Extensions: permessage-deflate。
- 必须在调用
upgrader.Upgrade()之前设置，对已建立连接无效 - 若客户端没发
Sec-WebSocket-Extensions: permessage-deflate，服务端即使设了也不会压缩，也不报错 - 浏览器默认带该头，但嵌入式设备、自研客户端、旧版 WebView（如 iOS 15 以下）常遗漏
conn.EnableWriteCompression(true) 才真正触发压缩
握手协商成功后，还需对每个连接显式启用写压缩，否则 WriteMessage() 仍发明文：
- 在
Upgrade()成功后立即调用conn.EnableWriteCompression(true) - 该调用必须在首次
WriteMessage()前，否则无效 - 可选：用
conn.SetCompressionLevel(websocket.CompressionNoContextTakeover)控制上下文复用，但无法调 zlib level（固定为 6）
压缩有硬编码阈值，小消息一律跳过
gorilla 实现中，permessage-deflate 仅对 ≥1024 字节的 TextMessage 或 BinaryMessage 帧尝试压缩——这是代码里写死的，不可配置。
- 测试时务必用 >2KB 的 JSON 或日志数组，否则 Wireshark 看不到
RSV1=1标志 - Protobuf 序列化后的二进制数据本身已高度压缩，再套
permessage-deflate效果微弱，甚至膨胀 - 小于 1024 字节的消息，
conn.IsCompressed()返回 false，不代表配置错了，只是被跳过
别手动套 flate.Writer，会和协议层冲突
有人试图在发消息前自己用 flate.NewWriter 包一层，这是危险操作：
- 协议层压缩 + 手动压缩 = 双重 deflate，客户端解压失败或乱码
- gorilla 的压缩发生在帧封装阶段，由底层
compression.go自动处理，你只需确保协商和启用正确 - 真有极端压缩需求（如 IoT 窄带），应换 zstd/snappy 自行序列化成二进制帧，绕过
permessage-deflate，但要承担客户端适配成本
最易被忽略的是：压缩状态是连接级的，不是每条消息独立判断；而阈值、客户端头、启用时机三者缺一不可——少一个，抓包看到的就全是明文帧。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
