因为php默认错误处理器直接输出并终止脚本，手动echo的json易受http状态码缺失、前置输出干扰或后续代码执行影响，导致前端解析失败；必须统一用exit(json_encode(...))封装响应，严格控制状态码、响应头与输出时机。
PHP自定义错误处理器里 echo json_encode() 为什么前端收不到？
因为 PHP 的默认错误处理器会直接输出并终止脚本，而你手动 echo 的 JSON 很可能被 HTTP 头（尤其是状态码）和已有输出干扰，导致前端解析失败或收到混合内容。关键不是“能不能输出 JSON”，而是“能不能干净、可控地返回标准响应”。
- 必须在触发错误前调用
http_response_code(500)（或其他对应状态码），否则默认是 200 OK - 必须确保没有前置输出（包括空格、BOM、
print、var_dump），否则header()会失败 - 建议统一使用
exit(json_encode(...))而非echo + die，避免后续代码意外执行
set_error_handler 中怎么区分 E_WARNING 和 E_USER_ERROR 并返回不同 JSON 结构？
PHP 的错误级别决定了是否进入自定义处理器（E_ERROR、E_WARNING、E_USER_ERROR 等都会进，但 E_NOTICE 默认不进，需显式开启）。你需要按需映射为 HTTP 状态码，并构造语义清晰的 JSON 字段。
-
E_WARNING→http_response_code(400)，"code": "invalid_input" -
E_USER_ERROR→http_response_code(401)或403，视业务而定，"code": "auth_failed" -
E_ERROR（如致命错误）→http_response_code(500)，"code": "server_error"，且不应暴露$message给生产环境
set_error_handler(function($severity, $message, $file, $line) {
if (!(error_reporting() & $severity)) {
return;
}
http_response_code(400);
$json = json_encode([
'success' => false,
'code' => 'invalid_input',
'message' => '参数校验失败',
'detail' => $_SERVER['REQUEST_URI'] ?? ''
]);
exit($json);
});
为什么 try-catch 捕获不到 parse error 或语法错误？
因为 parse error 属于编译阶段错误，在脚本加载时就中止了，根本不会进入运行时，所以 set_error_handler 和 try-catch 都无效。这类错误只能靠开发流程拦截（如 PHP-CS-Fixer、CI 中的 php -l）。
- 运行时的
throw new Exception()可被try-catch捕获，适合业务异常 -
set_error_handler只能捕获运行时警告/错误，不能捕获语法、未定义类、require 失败等 fatal error - 要覆盖 fatal error，需配合
register_shutdown_function()+error_get_last()判断是否为E_ERROR
如何让所有接口响应结构一致，连成功也走同一套 JSON 格式？
不要只在错误处理里写 JSON 输出逻辑。应该把响应封装成一个函数（比如 api_response()），在所有控制器出口统一调用——无论成功还是失败，都经过它。
- 成功路径：显式调用
api_response(['data' => $result]) - 错误路径：在
set_error_handler或catch块里调用api_response(['success' => false, ...], 400) - 该函数内部统一设置
Content-Type: application/json; charset=utf-8，并禁用输出缓冲干扰
真正容易被忽略的是：很多团队只修错误分支，却放任成功响应用 echo json_encode() 散落在各处，导致字段命名不一致（data / result / payload）、缺少 code、没有统一的 timestamp，后期联调和前端 SDK 就开始踩坑。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
