php json_encode() 默认格式化输出，需禁用 json_pretty_print 并添加 json_unescaped_unicode 等标志精简；gzip 压缩效果远优于 php 层优化，应优先配置 web 服务器启用 gzip 并支持 application/json。
PHP json_encode() 默认不压缩，必须手动关掉空白符
PHP 生成的 JSON 默认带空格、换行和缩进，体积明显变大。这不是 bug，是 json_encode() 的默认行为——它优先可读性，不是传输效率。
真正减小体积，核心就一条：加 JSON_UNESCAPED_UNICODE | JSON_UNESCAPED_SLASHES | JSON_NUMERIC_CHECK 这类标志位，但最关键的是去掉 JSON_PRETTY_PRINT（如果误加了）。
-
JSON_UNESCAPED_UNICODE：避免中文被转成uXXXX，单个汉字从 6 字节降到 3 字节（UTF-8） -
JSON_UNESCAPED_SLASHES：不转义/，对 API 响应影响小但能省几个字节 - 别用
JSON_PRETTY_PRINT，它会强制插入大量空格和换行，体积可能翻倍 - 如果数据里有大量数字字符串（比如
"123"），加JSON_NUMERIC_CHECK可转成数字类型，省掉引号和双引号
示例对比：
json_encode($data) → {"name": "张三", "id": "1001"} // 28 字节 json_encode($data, JSON_UNESCAPED_UNICODE) → {"name": "张三", "id": "1001"} // 同样内容，但中文不转义后更短
gzip 压缩比 JSON 内部优化更有效，但得看服务端配置
光靠 PHP 层精简 JSON，极限也就省 10%–30%；而启用 HTTP gzip，通常能压到原始体积的 20%–40%，效果立竿见影——前提是服务端允许且客户端支持。
立即学习“PHP免费学习笔记（深入）”；
- 确认 Web 服务器（Nginx/Apache）已开启 gzip，并包含
application/jsonMIME 类型 - PHP-FPM 环境下，
zlib.output_compression开启会干扰响应头，建议关掉，统一由 Web 服务器处理 - 检查响应头是否有
Content-Encoding: gzip，没有就说明没生效 - 注意：gzip 对极小 JSON（
不要在 PHP 里用 str_replace() 或正则“手动压缩” JSON
有人试过用 str_replace([' ', "n", "t"], '', $json) 去除空白，这很危险——会破坏字符串内的空格或换行，导致 JSON 解析失败。
- JSON 字符串值里合法含空格（如
{"msg": "hello world"}），删掉就变成"helloworld" - JSON 中的换行（
n）是字符串内容的一部分，不是格式符，不能随便 strip -
json_encode()本身不生成非法结构，自己用字符串函数硬改，等于绕过 JSON 编码器的安全保障 - 真要极致压缩（比如嵌入 HTML 的微数据），应改用
JSON_UNESCAPED_UNICODE | JSON_UNESCAPED_SLASHES组合，而不是文本层面 hack
PHP 8.1+ 的 JSON_THROW_ON_ERROR 不影响体积，但能避免静默失败
这个标志位本身不改变输出，但它让错误更早暴露——比如遇到无法序列化的资源（resource、闭包），json_encode() 不再返回 false，而是抛异常。这对调试压缩后出错的场景很关键。
- 旧写法：
$json = json_encode($data); if ($json === false) { /* 手动查 json_last_error() */ } - 新写法：
json_encode($data, JSON_THROW_ON_ERROR | JSON_UNESCAPED_UNICODE)，异常直接告诉你哪条数据坏了 - 尤其当压缩后字段变多、类型更敏感（比如
JSON_NUMERIC_CHECK把"0123"当数字转成123），这类错误更容易被忽略
压缩 JSON 本质是两层事：PHP 编码时少输出无用字符，HTTP 传输时用 gzip 压缩字节流。中间任何想“用字符串函数再压一压”的操作，基本都在破坏 JSON 的合法性。真正容易被忽略的点是——gzip 没生效时，所有 PHP 层优化都只是隔靴搔痒。