前言先做一个版本澄清PHP 8.4 并没有引入一套新的错误处理机制。如果你期待的是像新增一个异常基类错误全面异常化这种量级的变化那它并不存在。现在这套体系的地基是 PHP 7.0 打下的Throwable接口和Error类以及 PHP 8.0 把大量警告改成异常的那次调整PHP 8.4 在错误与弃用deprecation维度上真正落地的是几项增量变化。不过这些增量变化恰恰是升级到 8.4 之后最先在日志里炸出来的一批东西。典型症状是站点本身跑得好好的error_log每天涨几十兆里面清一色是Deprecated: Implicitly marking parameter ... as nullable is deprecated或者你自己的某个工具函数在被调用时突然输出一条Deprecated: Function xxx() is deprecated而代码里根本找不到trigger_error。本文按错误体系现状 → 8.4 到底改了什么 → 怎么用#[\Deprecated]管理自己代码的弃用 → 怎么统一收口的顺序讲清楚并给出一份可直接运行的错误收集器代码。一、先把 PHP 现在的错误体系摆清楚PHP 里有两条并行了几十年的线错误error来自引擎和扩展走error_reporting与错误处理器异常exception是语言级的抛出/捕获机制。它们的分界线如下。类型引入版本归属能否被catchThrowable接口PHP 7.0语言可以且是所有可捕获对象的共同父接口Error类PHP 7.0语言可以TypeError、ValueError都继承它ErrorException早于 7.0语言可以通常由set_error_handler转换生成Exception类早于 7.0语言可以业务异常应继承它E_WARNING/E_NOTICE等错误级别—引擎不可以只能被错误处理器拦截TypeError、ArgumentCountErrorPHP 7.0语言可以ValueErrorPHP 8.0语言可以两个必须记住的结论第一Error与Exception是兄弟不是父子。catch (Exception $e)抓不到TypeError。要兜底就必须写catch (Throwable $e)。第二PHP 8.0 起很多过去只报警告的情况改成了抛异常。这是 PHP 8.4 上排查问题时最容易误判的地方——错误日志里没有线索因为问题已经是以异常形式抛出的了。二、PHP 8.4 在错误与弃用维度真正改了四件事变化版本具体行为升级影响#[\Deprecated]属性8.4给用户态函数、方法、类常量含枚举 case打弃用标记调用时产生E_USER_DEPRECATED新增能力可主动使用E_STRICT错误级别移除、E_STRICT常量废弃8.4引擎早已不再产生该级别错误引用这个常量本身会触发弃用告警用error_reporting(E_ALL ~E_STRICT)的代码会开始报警向trigger_error()传E_USER_ERROR弃用8.4用异常替代它作为终止型错误老代码里的trigger_error($msg, E_USER_ERROR)会开始报警隐式可空参数implicitly nullable parameter弃用8.4function f(string $s null)这种写法开始报警应写成?string $s null第三方库会刷大量日志需升级依赖或临时降噪还有一件容易和 8.4 混淆的事致命错误fatal error带上完整堆栈是 PHP 8.5 的能力由 INI 项fatal_error_backtraces控制且默认开启。8.4 里遇到解析错误、函数重复声明这类致命错误依然只有一行Fatal error: ...和文件行号没有调用栈。如果你正在为看不到致命错误的调用链发愁需要的是升级到 8.5而不是在 8.4 上找配置。三、用#[\Deprecated]管理自己代码的弃用在 8.4 之前标记一个函数即将下线只有两种办法写注释调用方看不见或者在函数体里trigger_error(..., E_USER_DEPRECATED)每次调用都执行一次额外开销。8.4 把这件事变成了声明式的。属性类Deprecated的构造函数签名是__construct(?string $message null, ?string $since null)两个参数都会拼进最终的提示信息。可用的目标包括函数、方法、类常量。?php // deprecated_demo.php —— 需 PHP 8.4 declare(strict_types1); #[\Deprecated(message: use safe_fetch() instead, since: 1.4.0)] function legacy_fetch(string $url): string { return body of . $url; } function safe_fetch(string $url): string { return body of . $url; } // 反射也能读到弃用标记方便写禁止调用弃用 API的静态检查 $ref new ReflectionFunction(legacy_fetch); var_dump($ref-isDeprecated()); // bool(true) var_dump($ref-getAttributes(\Deprecated::class)[0] -newInstance()-since); // string(5) 1.4.0 set_error_handler(static function (int $no, string $msg): bool { printf([%d] %s\n, $no, $msg); return true; }); legacy_fetch(https://example.com); // 触发 E_USER_DEPRECATED被上面的处理器接住 safe_fetch(https://example.com); // 不触发 restore_error_handler();类常量同样可以标记这对枚举里某个 case 即将废弃很有用?php // 需 PHP 8.4 enum Channel: string { case Sms sms; case Email email; #[\Deprecated(message: use Email instead, since: 2.0.0)] case Fax fax; } $const (new ReflectionClass(Channel::class))-getReflectionConstant(Fax); var_dump($const-isDeprecated()); // bool(true) $case (new ReflectionEnum(Channel::class))-getCase(Fax); printf(case %s 的 backing value 是 %s\n, $case-getName(), $case-getBackingValue());注意一个关键事实#[\Deprecated]只负责喊一声不负责拦住。它不会阻止调用也不会中断流程。如果某个方法必须被阻断那要靠抛异常或者删除方法本身。另外这个属性在 PHP 8.4 以下完全无效——低版本上什么都不会打印需要跨版本一致的话仍要在函数体里手动trigger_error(..., E_USER_DEPRECATED)。四、隐式可空参数的弃用最先在日志里爆出来的那个这是 8.4 升级后日志量暴涨的头号原因。过去string $s null会被隐式理解成?string $s null8.4 起这个写法开始报Deprecated: Implicitly marking parameter $name as nullable is deprecated, the explicit nullable type must be used instead写法8.4 状态修正function f(string $s null)弃用function f(?string $s null)function f(array $a null)弃用function f(?array $a null)function f(callable $c null)弃用function f(?callable $c null)function f(Foo\Bar $x null)弃用public ?string $p null;本来就必须显式可空无需改动这个提示是在声明该函数的文件被编译时发出的而不是在函数被调用时。所以它会出现在完全没被调用过的函数上也会让靠运行时错误处理器收集的方案不一定抓得住——处理器注册时机晚于文件编译时就什么都收不到。排查它的正确姿势是看日志或做静态扫描而不是断点调试。代码实战一个可直接运行的错误收集器下面这段代码把 Warning、Notice 归一化处理把弃用按指纹聚合避免同一条信息刷爆日志并支持在测试环境把 Warning 直接升级成异常。?php // error_collector.php —— 需 PHP 8.4 declare(strict_types1); final class ErrorCollector { /** var arraystring, int 弃用指纹 命中次数 */ private array $deprecations []; /** var liststring */ private array $runtime []; public function register(bool $throwOnWarning false): void { set_error_handler(function (int $severity, string $message, string $file, int $line) use ($throwOnWarning): bool { // PHP 8.4 起 E_STRICT 已不再使用这里不再需要它 $names [ E_DEPRECATED E_DEPRECATED, E_USER_DEPRECATED E_USER_DEPRECATED, E_WARNING E_WARNING, E_USER_WARNING E_USER_WARNING, E_NOTICE E_NOTICE, E_USER_NOTICE E_USER_NOTICE, ]; $name $names[$severity] ?? (E_ . $severity); if ($severity E_DEPRECATED || $severity E_USER_DEPRECATED) { // 弃用只聚合不抛异常一个第三方库的弃用提示不该变成 500 $fingerprint $message . . $file; $this-deprecations[$fingerprint] ($this-deprecations[$fingerprint] ?? 0) 1; return true; } if ($throwOnWarning) { throw new ErrorException($message, 0, $severity, $file, $line); } $line0 sprintf([%s] %s in %s:%d, $name, $message, $file, $line); $this-runtime[] $line0; error_log($line0); return true; }); } /** return arraystring, int */ public function deprecations(): array { return $this-deprecations; } /** return liststring */ public function runtime(): array { return $this-runtime; } } // ---- 演示 ---- #[\Deprecated(message: use safe_parse() instead, since: 1.4.0)] function legacy_parse(string $json): array { return (array) json_decode($json, true); } $collector new ErrorCollector(); $collector-register(throwOnWarning: true); legacy_parse({a:1}); legacy_parse({a:2}); // Warning 在严格模式下被升级成异常 try { $arr []; $v $arr[not_exists]; } catch (ErrorException $e) { printf(捕获到: %s (%s:%d)\n, $e-getMessage(), $e-getFile(), $e-getLine()); } print_r($collector-deprecations());运行后会看到两件事弃用被聚合成一条计数为 2 的记录而越界的数组访问被ErrorException接住——这正是把错误和异常统一到一条通道上的标准做法。常见坑点❌ 听说8.4 有新的错误处理机制去catch一个并不存在的类型✅ 体系仍是ThrowablePHP 7.0ErrorPHP 7.0ErrorException8.4 新增的是弃用标记手段不是异常层次❌ 继续写error_reporting(E_ALL ~E_STRICT)✅E_STRICT这个级别在 8.4 已移除、常量本身也已废弃引用它会触发Deprecated。直接删掉这段掩码❌ 用trigger_error(参数非法, E_USER_ERROR)来终止流程✅ 该用法自 8.4 起弃用终止流程请抛异常throw new InvalidArgumentException(参数非法);并在全局兜底处统一转成 500 响应❌ 函数签名写成function f(string $s null)✅ 改成?string $s null。这是 8.4 升级后日志暴涨最常见的来源且第三方库往往比自己的代码更晚修❌ 以为打了#[\Deprecated]就能阻止别人调用✅ 它只产生E_USER_DEPRECATED提示调用照样执行。要阻断只能抛异常或删除方法❌ 在全局错误处理器里对E_DEPRECATED也抛异常✅ 生产环境的E_DEPRECATED只应记录与聚合一旦抛异常任何一个老依赖的弃用提示都会变成用户可见的 500❌try { ... } catch (Exception $e) { ... }作为全局兜底✅TypeError、ValueError、DivisionByZeroError都继承Error而非Exception必须写catch (Throwable $e)❌ 在 8.4 上找致命错误堆栈的开关✅ 那是 PHP 8.5 的fatal_error_backtraces默认开启8.4 上的替代方案是自己注册register_shutdown_function()配合error_get_last()补记录总结关注点PHP 8.4 的实际情况你应该怎么做错误处理机制本身无新机制地基是 7.0 的Throwable/Error用catch (Throwable $e)兜底区分Error与Exception用户态弃用标记新增#[\Deprecated]属性用在函数、方法、类常量上配合isDeprecated()做静态检查E_STRICT级别移除、常量废弃从error_reporting掩码里删掉E_USER_ERRORtrigger_error()的该用法弃用改用抛异常隐式可空参数8.4 起弃用签名改为?type $x null靠日志与静态扫描排查致命错误堆栈属于 PHP 8.5 的能力8.4 上用register_shutdown_function()error_get_last()兜底在 8.4 上做错误治理重点不是找新机制而是把两套通道合流用set_error_handler把引擎告警转成ErrorException用catch (Throwable)兜住所有可捕获对象再把弃用降级成聚合指标而不是噪声。这样无论后面升到 8.5 还是 9.0错误处理代码都不需要重写。