PHP 5.2 以下无 json_encode，需引入 Services_JSON 等兼容库或封装运行时检测，注意错误码常量缺失、键名大小写及手写编码风险。
PHP 5.2 以下没有 json_encode 怎么办
PHP 5.2 是 json_encode 和 json_decode 进入核心扩展的分水岭。低于这个版本（比如 5.1、5.0），这些函数根本不存在，直接调用会报 Fatal error: Call to undefined function json_encode()。
最直接的兼容方式是引入一个纯 PHP 实现的 JSON 库，比如 Services_JSON（PEAR 包）或更轻量的 jsonwrapper。但要注意：这些实现不处理资源类型、不支持 JSON_UNESCAPED_UNICODE 等 flag，且性能比原生低 3–5 倍。
- 优先检查运行环境：
if (function_exists('json_encode')) { ... }，避免在高版本上强制走兼容路径 -
Services_JSON需要require_once 'Services/JSON.php'，实例化后调用$json->encode($data)，注意它默认把中文转成 \uXXXX - 如果只读少量配置数据，可改用
serialize()+base64_encode()临时替代，但别用于前后端通信——格式不通用
PHP 5.2–5.3 中 json_last_error() 返回值不一致
PHP 5.2 的 json_last_error() 只返回整数错误码（如 JSON_ERROR_SYNTAX 是 4），而 5.3+ 才开始定义常量。若代码里写了 if (json_last_error() === JSON_ERROR_SYNTAX)，在 5.2 下会 Warning：undefined constant。
解决方法不是硬写数字，而是做运行时判断：
立即学习“PHP免费学习笔记（深入）”；
使用 JSON Schema 验证 JSON 数据，从示例 JSON 生成 schema，并将其转换为 TypeScript 接口、Python 数据类或 Markdown 文档。
- 用
defined('JSON_ERROR_SYNTAX')判断常量是否存在，否则 fallback 到数值比较 - 更稳妥的是封装一层：
function safe_json_last_error() { return function_exists('json_last_error') ? json_last_error() : 0; } - 别依赖
json_last_error_msg()—— 它直到 PHP 5.5 才加入，5.2–5.4 调用直接 fatal
旧版 PHP 里 json_decode($str, true) 的数组键名大小写问题
PHP 5.2 的 json_decode 对对象属性名大小写敏感，但转换为关联数组后，键名本身没问题；真正容易出错的是当 JSON 字符串里含重复键（如 {"id":1,"ID":2}），旧版解析器可能静默丢弃后者，新版则保留最后一个。
这不是函数 bug，而是底层解析器差异。如果你的接口接收第三方 JSON，且字段名大小写不统一（比如有的传 user_id，有的传 USER_ID），别指望 json_decode 自动归一化。
- 提前 normalize 键名：用正则把 JSON 字符串里的
"[A-Z]全转成小写再 decode（慎用，可能误伤字符串内容） - 更安全的是 decode 成对象，然后用
get_object_vars()+array_change_key_case()处理 - 永远校验关键字段是否存在：
isset($arr['user_id']) || isset($arr['USER_ID'])，别只查一种写法
为什么不要自己手写 json_encode 替代函数
有人为了“完全控制”或“绕过扩展依赖”，用 str_replace + foreach 拼 JSON 字符串。这在简单场景看似可行，但实际踩坑极多：
- 中文字符会被当成乱码拼进去，除非手动
mb_convert_encoding+urlencode再解，逻辑爆炸 - 单引号、换行符、反斜杠全得手动
addslashes，但addslashes不处理 \u 编码，JSON 标准要求必须转义 -
null、NaN、INF这些特殊值，原生函数有完整判定，自己写极易漏判导致语法错误
真要最小依赖，就用已验证的兼容库；想彻底避开 JSON，就换协议（比如用 http_build_query 传简单参数）。手写 encoder 是典型的“省事一时，debug 三天”。
