JSON解析失败但json_last_error()返回0，主因是UTF-8 BOM（\xEF\xBB\xBF）或不可见空白字符干扰；需用ltrim清理头部后再解析，并显式校验错误码。
JSON解析失败但json_last_error()返回0？检查BOM头和空白字符
ThinkPHP默认用json_decode()解析请求体或响应内容，但老旧API常在JSON字符串前塞一个UTF-8 BOM（\xEF\xBB\xBF）或不可见空白（如\u200b、换行符），导致json_decode()静默失败——json_last_error()可能返回JSON_ERROR_NONE，但结果却是null。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 收到原始数据后，先用
ltrim($raw, "\xEF\xBB\xBF\r\n\t ")清理头部BOM和空白 - 若来自
file_get_contents('php://input')或$request->getContent()，务必在json_decode()前做这步 - 不要依赖
is_null()判断解析结果，改用json_last_error() !== JSON_ERROR_NONE显式校验
ThinkPHP 6.x中Request::json()自动解析失效？手动接管更可靠
Request::json()底层调用json_decode($this->getContent(), true)，但它不处理编码异常、不重试、也不暴露原始错误上下文。遇到老旧API返回text/html却塞了JSON内容，或响应头Content-Type缺失/错写为application/json;charset=gbk时，直接抛异常或返回null。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 绕过
Request::json()，改用$raw = $request->getContent(); $data = json_decode($raw, true); - 加一层容错：对
mb_detect_encoding($raw) !== 'UTF-8'的情况，尝试mb_convert_encoding($raw, 'UTF-8', 'GBK') - 记录原始
$raw到日志（限长度，比如substr($raw, 0, 512)），方便排查格式问题
解析嵌套JSON字符串字段（如extra_info）时二次解析失败？警惕转义与双重编码
老旧API常把JSON结构序列化成字符串再塞进另一个JSON字段，比如{"user_id":123,"extra_info":"{\"name\":\"张三\",\"tags\":[\"vip\"]}"}。直接取$data['extra_info']是字符串，需再次json_decode()，但若前端误用JSON.stringify(JSON.stringify(obj))，会导致双层转义，json_decode()第一次解出来仍是带引号的字符串，第二次才真正解构。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 检测字段是否为JSON字符串：用
is_string($val) && $val[0] === '{' || $val[0] === '['粗筛 - 安全二次解析：先
json_decode($val, true)，若结果仍为string且疑似JSON格式，再试一次 - 避免无限递归：限制最多解析2层，第三层直接跳过或报warning
使用json_decode($str, true, 512, JSON_BIGINT_AS_STRING)防整数溢出
老旧API常返回超长数字ID（如微信OpenID、支付宝流水号），PHP默认将大整数转为float，精度丢失。ThinkPHP未默认启用JSON_BIGINT_AS_STRING，导致"12345678901234567890"变成1.2345678901235E+19。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 所有关键数字字段（ID、金额、时间戳）解析时，必须传第四个参数
JSON_BIGINT_AS_STRING - ThinkPHP 6.x中可在全局中间件里重写
Request的json()方法，或封装一个safeJsonDecode()工具函数 - 注意兼容性：
JSON_BIGINT_AS_STRING仅PHP ≥ 5.4支持，低于此版本需用正则预处理数字字段
老旧API的“兼容”不是加个try-catch就完事，真正麻烦的是那些不报错、不提示、只悄悄丢精度或截断的边缘情况——尤其是BOM、编码混杂、双重JSON字符串、大整数这几个点，一漏就是线上查三天。
