PHP 8.3 未新增 RESTful 接口语法，但底层行为更严格：json_encode() 默认不转义 Unicode（需传 0 恢复转义），php://input 在 FPM 下易因缓冲或 Content-Type 被提前读空，http_response_code() 后输出即致命错误，空白符导致 headers_sent() 静默失败。
PHP 8.3 本身没新增 RESTful 接口语法，写法和 8.0/8.1 一致，但几个底层行为更严格——json_encode() 默认不转义 Unicode、file_get_contents('php://input') 在某些 SAPI（如 PHP-FPM 的某些配置）下可能提前 EOF、http_response_code() 调用后若再输出会直接报致命错误（而非警告）。别被“新版”误导，重点是规避这些隐性变化。
怎么判断是否在 PHP 8.3 环境下触发了 json_encode 的 Unicode 行为变化
PHP 8.3 默认启用 JSON_UNESCAPED_UNICODE，即中文不再转成 \u4f60\u597d。这本是好事，但如果你的前端老版本 JSON 解析器（比如某些嵌入式设备或旧 WebView）只认转义格式，就会解析失败。
- 检查响应体：用
curl -i或浏览器 DevTools 查看原始响应，确认中文是明文还是 \u 序列 - 强制兼容旧解析器：显式传参
json_encode($data, JSON_UNESCAPED_UNICODE | JSON_UNESCAPED_SLASHES)不够，得加JSON_UNESCAPED_UNICODE反向禁用——实际要写json_encode($data, 0)（因为 8.3 默认 flag 是JSON_UNESCAPED_UNICODE，传 0 才重置） - 别依赖 php.ini 配置：
json.encode_serializable这类 ini 项在 8.3 已废弃，改用函数参数控制
PHP 8.3 下 file_get_contents('php://input') 读不到数据的三个真实原因
不是代码写错了，是 8.3 对输入流管理更激进。常见于 Nginx + PHP-FPM 组合，尤其启用了 fastcgi_buffering on 或 proxy_buffering 时。
-
$_POST不为空但file_get_contents('php://input')返回空字符串：说明请求体已被 PHP 提前解析（比如 Content-Type 是application/x-www-form-urlencoded），此时不要混用两者，直接用$_POST - Content-Type 是
application/json却读不到：检查 Nginx 是否开了client_max_body_size限制，8.3 默认更早抛出 413，且不返回 body；同时确认 PHP-FPM 的request_terminate_timeout没被设得太短 - 本地 CLI 测试正常，线上 FPM 就失败：大概率是
php://input在 FPM 下被缓冲层截断，加一行fflush(STDIN)无效，正确做法是在读取前加rewind(STDIN)（仅限 CLI）；FPM 环境必须靠file_get_contents('php://input')，且确保没其他扩展（如 Suhosin）干扰
PHP 8.3 的 http_response_code() 必须在 echo 前调用，否则直接 Fatal Error
8.2 及以前只是 Warning，8.3 升级为 Fatal error: Uncaught ValueError，且无法被 set_error_handler 捕获。一旦触发，整个脚本中断，连日志都写不了。
立即学习“PHP免费学习笔记（深入）”；
- 最稳妥的防护：入口第一行就写
if (headers_sent($file, $line)) { http_response_code(500); exit('Headers already sent at ' . $file . ':' . $line); } - 别信 IDE 自动补全：有些插件会在
echo后自动补header()，8.3 下这种代码一运行就崩 - 状态码和 header 顺序不能反：必须先
http_response_code(404)，再header('Content-Type: application/json')，最后echo json_encode(...)；反过来会触发 Fatal
为什么 PHP 8.3 更容易因空白符导致接口静默失败
8.3 默认开启 output_buffering = 4096，看似能容错，实则掩盖问题——空白符仍在，只是被缓存了。一旦 buffer 满或脚本结束，header() 就失效，但错误不会立刻暴露。
- 检查所有包含文件末尾：用编辑器显示不可见字符，确保
?>后没有换行或空格（哪怕一个空格也会让headers_sent()返回 true） - 禁用 output_buffering 调试：临时在 php.ini 设
output_buffering = Off，让问题立即浮现 - 用
ob_start()替代全局 buffering：在入口手动开 buffer，业务逻辑里用ob_get_clean()拿到输出再统一header()和echo，可控性更强
PHP 8.3 的“严格”不是为了难为你，而是把过去模糊的边界划清了。最容易被忽略的是：它不会给你留 warning 的余地，出错就是 fatal，而且往往卡在你根本没想到的位置——比如某个被 include 的配置文件末尾多了一个空行。
