php json_encode() 默认行为会显著拖慢接口性能，因其生成冗余空白、转义字符及未裁剪字段；应启用优化标志、手动裁剪数据、流式处理大数组并升级至 php 8.1+ 启用 json_throw_on_error。
PHP json_encode() 默认行为会拖慢接口
默认用 json_encode() 输出数组，会产生大量空白和冗余键名，尤其嵌套深、字段多时，体积直接翻倍。这不是“美观问题”，是真实影响 HTTP 传输时间、移动端解析耗时、CDN 缓存效率。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 始终加
JSON_UNESCAPED_UNICODE | JSON_UNESCAPED_SLASHES | JSON_NUMERIC_CHECK标志 —— 避免中文转义成\u4f60，斜杠不转义，数字不包引号 - 禁用
JSON_PRETTY_PRINT，它加换行缩进，纯属开发期调试用，上线必须关 - 如果后端只给前端用，且确定无 IE8 等古董浏览器，可加
JSON_INVALID_UTF8_SUBSTITUTE防止非法 UTF-8 字符导致整个编码失败
字段冗余常来自 PHP 数组结构本身
不是 JSON 格式的问题，是 PHP 里没做裁剪就硬塞进 json_encode()：比如查数据库用 fetch_all(MYSQLI_ASSOC) 得到全字段，但前端只用其中 3 个；或对象里带了 $_meta、$container 这类内部属性。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 不要依赖前端“自己过滤”，在 PHP 层用
array_intersect_key()或显式构造白名单数组 - 对对象输出，优先用
JsonSerializable接口，在jsonSerialize()方法里 return 只需的字段 - 避免用
get_object_vars($obj)直接导出 —— 它会把 protected/private 属性变成\0*\0prop这种丑陋键名，还可能泄露敏感字段
大数组用 yield 流式 JSON 拼接更省内存
当要返回几千条记录（如日志列表、导出快照），一次性 json_encode($hugeArray) 会吃光内存，甚至触发 OOM。不是 JSON 函数慢，是 PHP 把整个数组载入内存再处理。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 用
yield逐条生成数据，配合手动拼接 JSON 数组结构（开头"["，每条加逗号分隔，结尾"]"） - 关键点：首条不加前置逗号，末条不加尾逗号 —— 可用布尔标记或
implode()分段处理 - 注意字符编码：所有片段必须统一 UTF-8，否则
json_decode()在 JS 端会静默失败 - 这种写法绕过了
json_encode()的校验，务必确保每个 yield 出来的子项本身是合法 JSON 片段（比如字符串已用json_encode()处理过）
PHP 8.1+ 的 JSON_THROW_ON_ERROR 能暴露真正瓶颈
旧代码常用 if (false === $json = json_encode(...)) 判断失败，但不告诉你哪出错。结果是接口返回空串或 null，前端报 “SyntaxError: Unexpected token” 却找不到源头。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 升级到 PHP 8.1+ 后，强制加
JSON_THROW_ON_ERROR，让错误直接抛出异常，堆栈能定位到具体字段值（比如某个DateTime对象没实现JsonSerializable） - 配合
set_error_handler()捕获E_WARNING级别的 JSON 错误（如深度超限），比静默失败更容易排查 - 注意：
json_last_error_msg()在多线程/协程环境下不可靠，别依赖它取错误信息
最常被跳过的其实是字段裁剪这步 —— 开发者总想着“反正前端会忽略多余字段”，但忘了 gzip 压缩率对重复键名极度敏感，一个 "user_id" 在 1000 条里出现 1000 次，压缩前和压缩后体积差得远。别省那几行数组过滤代码。
