php 8.4 错误处理更严格可预测：typeerror 变为不可抑制的 throwable 异常，session_start() 失败返回 false 需显式检查，display_errors 默认关闭须手动启用，set_error_handler 不捕获致命错误，统一捕获需用 catch (throwable) 或 set_exception_handler 配合 shutdown 函数。
PHP 8.4 的错误处理机制不是“换了一套新 API”，而是把原有机制变得更严格、更可预测——尤其在类型错误、会话反序列化、错误静默行为上。直接改代码往往不如先理解它“为什么突然报错”。
TypeError 不再是 Warning，而是真异常
PHP 8.4 中，函数签名声明了类型但传入不兼容值时，TypeError 会被抛出（而非 PHP 7.x 的 E_WARNING），且无法被 set_error_handler() 捕获，只能用 try-catch。
- 比如
function foo(string $s): int { return strlen($s); }，调用foo(null)会直接throw TypeError -
set_error_handler()对TypeError完全无效——它只处理E_WARNING、E_NOTICE等传统错误 - 若你依赖
@抑制这类错误，PHP 8.4 下会失效；必须显式catch (TypeError $e) - 注意：自定义异常类继承
Exception不能捕获TypeError，得用catch (TypeError $e)或更宽泛的catch (Throwable $e)
session_start() 失败不再静默返回 false
PHP 8.4 默认关闭 display_errors，且 session_start() 在失败时不触发传统错误，只返回 false，容易误判为“没做任何事”。
- 必须主动检查返回值：
if (!session_start()) { $err = error_get_last(); error_log('Session failed: ' . ($err['message'] ?? 'unknown')); } - 常见根本原因：旧 session 文件含 PHP 7.x 序列化数据（如
__wakeup调用已移除类）、session.save_path目录不可写、或路径被设为空字符串 - 临时绕过反序列化失败：加
ini_set('session.serialize_handler', 'php_serialize');（仅限调试，不解决兼容性） - 生产环境别用
@session_start()——它会吞掉所有上下文，让问题更难定位
error_reporting 和 display_errors 必须显式配置
PHP 8.4 启动时默认不启用 display_errors，即使 error_reporting(E_ALL) 生效，你也看不到任何提示。
- 开发环境务必加这两行（放在入口脚本最开头）：
error_reporting(E_ALL); ini_set('display_errors', '1'); - 生产环境禁用
display_errors，但必须确保log_errors = On且error_log路径可写，否则错误就真的“消失”了 -
set_error_handler()仍只捕获非致命错误（E_WARNING、E_NOTICE等），对E_ERROR、TypeError、ParseError无效 - 想统一兜底？
set_exception_handler()+register_shutdown_function()配合error_get_last()是唯一覆盖全部场景的方式
最易被忽略的一点：PHP 8.4 对“错误是否可恢复”的边界收得更紧——TypeError、ValueError、ArithmeticError 全部是 Throwable，但它们不是 Exception 子类。用 catch (Exception $e) 会漏掉它们，必须升级为 catch (Throwable $e) 或分层捕获。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
