PHP 8.2 接口异常主因是框架自动解码/解析篡改原始请求体：需用 php://input 获取原始流，验签等关键逻辑必须基于此重建参数；POST 表单需手动解析 stdin；JSON 请求禁用自动解析并校验编码；枚举响应须用 ->value，反序列化须用 tryFrom。
PHP 8.2 接口返回空数组、null、乱码或结构错乱，不是配置没生效就是原始输入被框架悄悄改过——比如 Laravel 的 $request->all() 会自动 urldecode，而签名验签要求原始字节流，一解就崩。
确认请求原始体是否被篡改
第一步：绕过框架封装，直接读取原始输入流。在中间件或控制器开头插入：
$raw = file_get_contents('php://input');
第二步：对比 $raw 与 $request->all() 或 $request->query() 的键值差异。若中文参数在 $raw 中是 %E5%BC%A0%E4%B8%89，但在 $request->get('name') 中已变成 张三，说明框架已执行自动解码——【所有验签、日志记录、防重放逻辑必须基于 $raw 重建参数，绝不可用 $request->xxx 方法】。
立即学习“PHP免费学习笔记（深入）”；
第三步：对 POST 表单类请求，需额外检查 Content-Type: application/x-www-form-urlencoded 是否触发了 PHP 自动解析。此时 $_POST 已污染，php://input 在该类型下为空，必须改用 file_get_contents('php://stdin') 并手动 parse_url_decode。
检查 JSON 请求体是否被重复解析
方法一：禁用 Laravel/Symfony 的自动 JSON 解析
在中间件中调用 $request->getContent() 获取原始 JSON 字符串后，立刻用 json_decode($content, true, 512, JSON_THROW_ON_ERROR) 解析一次。不要依赖 $request->json()->all() ——它内部可能已调用过 json_decode，再调用会导致资源耗尽或返回 null。
方法二：验证 JSON 编码完整性
对原始 $content 执行 json_last_error()，非零即失败；若为 JSON_ERROR_UTF8，说明前端发来的是 GBK 编码的 JSON，需在入口加 mb_convert_encoding($content, 'UTF-8', 'GBK') 再 decode。
排查枚举字段序列化异常
第一步：定位出问题的枚举属性，例如 OrderStatus::PENDING 在响应中变成空对象 {}。
第二步：确认该枚举是否为 BackedEnum（即声明了 :string 或 :int）。普通 enum 不实现 JsonSerializable，json_encode() 默认输出空对象。
第三步：强制使用 ->value 输出。写法：'status' => $order->status->value。若需兼容 label 展示，改用 'status_label' => $order->status->label()，但注意 label() 方法必须显式定义，不能依赖未声明的方法。
第四步：检查反序列化路径。若前端传回 {"status": "pending"}，服务端必须用 OrderStatus::tryFrom('pending') 而非 new OrderStatus('pending') ——后者会直接报错，【BackedEnum 构造不可 new，只能用 tryFrom 或 from】。
