在workerman 4.0.41中启用gzip压缩需手动干预传输层：先确认zlib可用，http下按长度阈值压缩并显式设content-encoding头，tcp/websocket用标识字节或握手协商压缩，且须显式释放内存防泄漏。
在 Workerman 4.0.41 中为高频数据流启用 Gzip 压缩，需绕过框架默认行为直接干预二进制传输层，否则压缩后客户端无法识别 Content-Encoding 或解压失败，导致 JSON 解析错误或空白响应。
确认 PHP 环境支持 gzencode
执行 php -r "echo function_exists('gzencode') ? 'ok' : 'missing';"，返回 ok 才能继续。若返回 missing，说明 PHP 编译时未启用 zlib 扩展，需重新编译或安装 php-zlib 包。
这一步不可跳过——【Workerman 不会自动检测 zlib 是否可用，调用 gzencode 失败时仅静默返回 false，后续 send() 发送空数据】。
HTTP 协议下手动注入 Gzip 压缩头
方法一：服务端压缩 + 显式设置响应头
在 onMessage 或 onRequest 回调中，对响应体做压缩并手动添加头：
① 判断原始数据长度是否 ≥ 1024 字节（小于该值压缩后可能更大，反而增加传输量）；
② 调用 $compressed = gzencode($raw_data, 6)，压缩级别设为 6（平衡速度与压缩率）；
③ 使用 $response->header('Content-Encoding', 'gzip') 和 $response->header('Vary', 'Accept-Encoding')；
④ 调用 $response->end($compressed) 发送压缩体。
注意：不能用 ob_gzhandler 或 zlib.output_compression，Workerman 的 HTTP 响应不走 PHP 默认输出缓冲。
TCP/WebSocket 自定义协议压缩
方法一：前置单字节标识 + zlib 压缩
发送前构造协议包：$packet = "\x01" . zlib_encode($data, ZLIB_ENCODING_DEFLATE)；
接收端先读 1 字节判断标志位，若为 \x01，则用 zlib_decode(substr($raw, 1)) 解包。
方法二：兼容旧客户端的 fallback 设计
客户端首次连接时发握手包带 {"enc":"gzip"}，服务端记录连接上下文；后续仅对该连接启用压缩，避免未声明支持的客户端崩溃。
【务必在 Connection 实例上绑定 compress_enabled 属性，不要用全局变量或静态数组缓存状态，否则多进程下状态错乱】。
规避常见内存泄漏陷阱
每次压缩都生成新字符串，PHP 的引用计数机制不会自动释放中间变量。必须显式置空：
unset($raw_data); $raw_data = null;
在高并发长连接场景下，漏掉这步会导致每个连接持续占用数 MB 内存，30 分钟后进程 RSS 暴涨至 2GB+。
