ThinkPHP 报 Parse error: syntax error, unexpected ‘…’ 或直接返回空响应，大概率不是 JSON 语法错，而是输入流被二次解码、BOM 头干扰、或 input() 读取方式不匹配 Content-Type。
为什么 input(‘param’) 读 JSON 会出错
ThinkPHP 默认把所有请求参数（包括 application/json 的原始 body）塞进 $_POST，但 JSON 数据根本不会自动进 $_POST —— 它只在 php://input 里。用 input(‘param’) 去读，实际是查空数组，返回 null 后再 json_decode(null)，就触发 PHP 的 silent failure，后续逻辑崩掉。
真正该用的是 input(”, ”, false)（第三个参数设为 false 表示不自动过滤/转换）更稳妥的做法是手动读取：file_get_contents(‘php://input’)，再判断是否为空或含 BOM如果前端发的是 Content-Type: application/json;charset=UTF-8，但带 UTF-8 BOM（如 Windows 记事本保存的 JSON），json_decode() 会直接失败，错误提示却像语法错
json_decode() 返回 null 却没报错？检查这三处
ThinkPHP 不会拦截 json_decode() 的失败，它只负责传参。返回 null 且 json_last_error() 是 JSON_ERROR_SYNTAX，不代表 JSON 写错了，很可能是：
原始数据含不可见字符：用 hexdump -C 或 bin2hex($raw) 看前几个字节，确认有没有 ef bb bf（UTF-8 BOM）编码不一致：前端用 GBK 发 JSON，PHP 用 UTF-8 解，json_decode() 拒绝处理，但不抛异常数据被框架中间件提前处理过：比如开启了 app_middleware 里的 CheckRequest，某些版本会悄悄调用 stripslashes()，把 {"key":"a\"b"} 变成 {"key":"a"b"}，语法就毁了
用 Request::instance()->getInput() 还是 input(”, ”, false)
ThinkPHP 5.1+ 中，Request::instance()->getInput() 和 input(”, ”, false) 都能拿到原始 body，但行为有差异：
立即学习“PHP免费学习笔记（深入）”；
input(”, ”, false) 会跳过所有过滤器（如 htmlspecialchars），适合纯 JSON 场景，但要注意它仍可能受 default_filter 配置影响Request::instance()->getInput() 更底层，绕过所有 input 处理逻辑，返回原样字符串，推荐用于调试阶段定位问题二者都不自动 trim()，如果 POST 工具（如 curl）多加了换行或空格，json_decode() 也会失败，建议先 trim($raw)
兼容 multipart/form-data + JSON 混合提交的写法
有些前端用 FormData 提交文件 + JSON 字符串字段（如 form.append(‘data’, JSON.stringify(obj))），这时不能用 php://input —— 它在 multipart 场景下是空的。必须走 $_POST + 手动 decode：
先检查 $_SERVER[‘CONTENT_TYPE’] 是否含 multipart/form-data若命中，从 $_POST[‘data’] 取值，再 json_decode(stripslashes($_POST[‘data’]), true)注意：magic_quotes_gpc 已废弃，但某些老旧服务器或兼容层仍可能开启，stripslashes() 是保险动作别用 input(‘data’) 直接解，它默认对字符串做 htmlspecialchars，会把 " 留着，导致 json_decode() 失败
最易忽略的点：开发时用 Postman 测试没问题，上线后 Nginx 加了 client_max_body_size 限制或启用了 gzip，body 被截断或乱码，json_decode() 依然只返回 null —— 这时候得看 access log 的请求体长度，而不是盯着 PHP 错误日志。
评论(0)