微信小程序wx.request需客户端设置'Accept-Encoding': 'gzip'且服务端返回Content-Encoding: gzip，PHP可用ob_gzhandler手动启用压缩，配合JSON键名精简、空字段过滤、时间戳整型化等优化可将体积压至20%～30%。
PHP 后端开启 gzip 压缩响应体
小程序（尤其是微信小程序）的 wx.request 默认支持接收 gzip 压缩的响应体，但前提是服务端明确返回 Content-Encoding: gzip 且内容确实被压缩。PHP 自身不自动压缩输出，需手动启用。
最稳妥的方式是在 Web 服务器层处理（如 Nginx 开启 gzip on），但如果只能操作 PHP 代码（例如共享主机、SaaS 环境），可用 ob_gzhandler：
if (isset($_SERVER['HTTP_ACCEPT_ENCODING']) && strpos($_SERVER['HTTP_ACCEPT_ENCODING'], 'gzip') !== false) {
ob_start('ob_gzhandler');
} else {
ob_start();
}
注意：ob_gzhandler 要求 PHP 编译时启用了 zlib，且不能在已开启 output buffering 的情况下重复调用；若用框架（如 Laravel、ThinkPHP），优先查其内置的响应压缩配置，避免手动干预造成冲突。
对 JSON 数据做精简而非单纯压缩
gzip 对重复文本高效，但 JSON 中大量键名（如 "user_id"、"created_at"）冗余明显。压缩前先做“语义精简”，收益常高于纯二进制压缩。
立即学习“PHP免费学习笔记（深入）”；
- 用短键名：把
"user_id"→"uid"，"is_active"→"a"（需前后端约定好映射表） - 移除空字段：
array_filter($data, function($v) { return $v !== null && $v !== ''; }) - 时间戳统一用 int（
time()）而非 ISO8601 字符串，省 15+ 字节/字段 - 避免嵌套过深的数组，扁平化结构（如把
["data" => ["user" => [...]]]改为["uid" => ..., "uname" => ...]）
这类精简后，再经 gzip，体积常能压到原始 JSON 的 20%～30%。
避免在 PHP 中用 json_encode 压缩失败
json_encode 本身不压缩，但常见错误是误以为加了 JSON_UNESCAPED_UNICODE 就能减小体积——它只影响中文是否转义，对英文/数字字段无作用；反而若漏掉 JSON_UNESCAPED_SLASHES，斜杠被转义（\/）会额外增大小程序解析负担。
推荐稳定组合：
json_encode($data, JSON_UNESCAPED_UNICODE | JSON_UNESCAPED_SLASHES | JSON_NUMERIC_CHECK)
其中 JSON_NUMERIC_CHECK 防止数字被转成字符串（如 "123" → 123），节省引号和类型判断开销。
小程序端必须设置 header 接收 gzip
即使 PHP 正确返回了 gzip 内容，若小程序请求没声明支持，服务端通常会退回明文响应。务必在 wx.request 中显式设置：
header: {
'Accept-Encoding': 'gzip'
}
否则 Nginx / Apache 可能跳过压缩逻辑，PHP 的 ob_gzhandler 也可能因 HTTP_ACCEPT_ENCODING 不匹配而失效。这个 header 容易遗漏，且无报错提示，只能靠抓包（如用 Charles 查看响应头是否含 Content-Encoding: gzip）确认。
传输数据大小不是单点优化问题，键名精简、响应头协商、PHP 输出控制、小程序客户端适配，四者缺一不可；其中最容易被忽略的是客户端 header 设置和服务器 gzip 开关状态的一致性验证。
