PHP 8.4未新增错误处理机制，但将部分E_WARNING/E_NOTICE升级为Fatal error，导致set_error_handler失效；需用try-catch显式捕获TypeError/ValueError，并配合静态分析预防。
PHP 8.4 没有新增错误处理机制，它沿用 PHP 7.4–8.3 的整套错误与异常模型，但对底层行为做了更严格的约束——这意味着你“用得不规范”，就更容易触发致命错误（Fatal error），而不是以往的 Warning 或静默失败。
为什么 set_error_handler 不再能捕获所有非致命错误
PHP 8.4 强化了类型系统和只读语义，导致部分过去被归为 E_WARNING 或 E_NOTICE 的问题，现在直接升级为 Fatal error。例如：
-
readonly属性在构造后被修改（如$this->id = 123）→ 立即Fatal error: Cannot modify readonly property，无法被set_error_handler()捕获 - 类型声明不匹配（如函数参数期望
int，传入null）→Fatal error: Uncaught TypeError，同样绕过错误处理器 - 访问未初始化的只读属性（
public readonly string $name;但没在构造中赋值）→Fatal error: Uninitialized readonly property
这些都不是“可恢复错误”，set_error_handler() 对它们完全无效。你必须靠静态分析（PHPStan）、IDE 提示、以及构造逻辑自查来预防，而不是指望运行时兜底。
try-catch 要明确捕获 TypeError 和 ValueError
PHP 8.4 继续强化类型错误的抛出行为，TypeError 和 ValueError 已成为标准异常类，且默认不被 Exception 捕获（因它们不继承 Exception，而是继承 Error）。所以旧写法：
立即学习“PHP免费学习笔记（深入）”；
try {
json_decode('{', true);
} catch (Exception $e) {
// ❌ 不会进入这里
}
正确写法是显式捕获：
try {
json_decode('{', true);
} catch (TypeError | ValueError $e) {
// ✅ 这里能捕获 JSON 解析失败、类型转换失败等
} catch (Exception $e) {
// 其他业务异常
}
- 漏掉
TypeError可能导致 API 接口在传错参数时直接 500，而不是返回结构化错误响应 -
ValueError常见于DateTimeImmutable::__construct()、mb_strlen()等函数传入非法值 - PHP 8.4 中，
json_decode()、unserialize()、preg_match()等函数在失败时更倾向抛出ValueError而非返回false
error_reporting(E_ALL) 在 PHP 8.4 下的实际效果
启用 error_reporting(E_ALL) 仍有效，但它**只影响传统错误（E_WARNING、E_NOTICE 等）**，对 Fatal error 和 Error 类异常无作用。而 PHP 8.4 中越来越多场景会直接触发后者。
- 开发环境建议：保持
error_reporting(E_ALL)+display_errors=1，但必须配合set_exception_handler()捕获未处理的Error子类 - 生产环境必须关闭
display_errors，否则Fatal error信息会直接输出到 HTML，暴露路径、类名甚至变量内容 - 别依赖
@抑制符处理类型错误——它对Fatal error完全无效，且会让 IDE 和静态分析工具失效
register_shutdown_function 是最后防线，但别滥用
当 Fatal error 发生时，脚本会立即终止，但 register_shutdown_function() 仍会被调用。你可以用它做最后的日志记录：
register_shutdown_function(function () {
$error = error_get_last();
if ($error && in_array($error['type'], [E_ERROR, E_PARSE, E_CORE_ERROR, E_COMPILE_ERROR, E_USER_ERROR])) {
error_log("FATAL: {$error['message']} in {$error['file']}:{$error['line']}");
// 可选：发送告警、清理临时文件
}
});
- 它不能阻止错误发生，也不能恢复执行，仅用于“事后留痕”
- 不要在里面尝试
echo或header()—— 输出可能已被缓冲或发送，造成 headers already sent 错误 - PHP 8.4 中，
error_get_last()在只读属性写失败等场景下能取到准确的Fatal error信息，这是比以前更可靠的兜底手段
真正规范的做法，不是靠层层兜底去“接住”错误，而是让类型声明、构造逻辑、属性初始化在编译期和实例化阶段就杜绝非法状态——PHP 8.4 的严格性，本质是在倒逼你写更确定、更自解释的代码。
