PHP 8.3接口返回空数据（200状态但body为空）需分层排查：先加调试代码确认执行路径，再用curl -v检查Content-Length；重点排查JIT兼容性、严格返回类型截断、废弃函数、输出缓冲清空及Content-Type头覆盖问题。
PHP 8.3 接口返回数据为空，不是报错也不是超时，而是响应体里干干净净——HTTP状态码200、header正常、但body里只有空字符串或{}，这种静默失败最容易耽误上线节奏。
先确认“空”到底发生在哪一层
第一步：在接口入口顶部加三行调试代码，不要跳过：
error_reporting(E_ALL);
ini_set('display_errors', '1');
file_put_contents('/tmp/php83-debug.log', print_r($_SERVER, true) . "\n" . file_get_contents('php://input') . "\n", FILE_APPEND);
第二步：用curl手动发一次请求，带-v参数看完整交互：
curl -v http://localhost/api/test.php
第三步：检查返回的Content-Length头。如果值是2（对应{}）或0，说明PHP脚本确实执行完了但没echo任何东西；如果curl卡住或直接断连，问题不在业务逻辑而在PHP运行层——比如8.3新增的strict_types强制校验导致致命错误被静默吞掉。
立即学习“PHP免费学习笔记（深入）”；
检查PHP 8.3特有陷阱
方法一：查看是否启用了JIT并触发了不兼容行为
在php.ini中临时注释掉opcache.jit=1205，重启PHP-FPM后重试。PHP 8.3默认开启JIT，某些扩展（如xdebug 3.2以下、旧版swoole）与JIT共存时会导致json_encode()等函数返回null而不报错。
方法二：验证return类型声明是否引发静默截断
如果接口函数写了-> array|false这样的严格返回类型，但实际执行中某处抛出了Warning（例如array_merge(null, [])），PHP 8.3会直接终止函数并返回null，且不触发任何错误日志。把函数签名改成-> mixed临时绕过，再逐行加error_log()定位中断点。
【关键前提】必须关闭opcache.enable_cli=1（CLI模式下OPcache默认开启），否则var_dump()和error_log()可能被缓存机制屏蔽，你看到的日志永远是上一次的结果。
逐段剥离响应生成链路
第一步：绕过所有业务逻辑，直接输出最简数据：
echo json_encode(['debug' => 'alive'], JSON_UNESCAPED_UNICODE); exit;
第二步：如果上一步能正常返回，说明问题出在数据组装环节。重点检查：
• 是否用了8.3废弃的函数（如create_function、each）导致脚本提前退出；
• 是否在foreach中对数组做了unset()后继续用key()，PHP 8.3会返回null而非警告；
• 是否调用了json_last_error_msg()但没重置错误状态，导致后续json_encode()始终返回false。
第三步：若数据组装无误，检查输出缓冲是否被意外清空。
在接口末尾加ob_end_flush(); echo "END";，如果页面只显示"END"，说明前面的json_encode()结果被ob_clean()或类似操作抹掉了。
第四步：确认Content-Type头是否被覆盖。
PHP 8.3对header()的校验更严，如果之前已发送过header('Content-Type: text/html')，后续再header('Content-Type: application/json')会失败且不报错，浏览器按text/html解析空响应体——此时curl -I能看到两个Content-Type头，第二个无效。
