fatal error会直接终止脚本执行，无法被try-catch捕获，必须用register_shutdown_function()和error_get_last()兜底；warning不中断执行，可通过set_error_handler()转为异常；e_all包含warning和fatal error的报告，但不改变其行为。
Fatal error 会直接终止脚本执行
只要触发 Fatal error，PHP 解析器或运行时引擎就会立刻停止后续所有代码执行，不返回任何输出（除非已提前 flush）。常见场景包括：
• 调用未定义的函数，如 call_undefined_function()
• 实例化不存在的类，如 new NonExistentClass()
• 重复定义函数或类
• 内存耗尽（Fatal error: Allowed memory size exhausted）
这类错误无法被 try-catch 捕获，因为它们不属于 Exception 体系；必须靠 register_shutdown_function() + error_get_last() 做兜底记录。
Warning 不中断执行但暴露潜在风险
Warning 是运行时发出的非致命提示，脚本会继续往下跑。典型例子：
• include 'missing.php' 找不到文件
• 用 0 当除数：$a / 0
• 使用了已弃用的函数（PHP 8.0+ 中部分 Deprecated 提升为 Warning）
它不会进 catch 块，但可通过自定义错误处理器（set_error_handler()）捕获并转为异常——前提是该 Warning 没发生在解析阶段（比如 include 失败是运行时，能捕获；而 require 失败若在顶层，可能直接变 Fatal error）。
E_ALL 是否包含 Warning 和 Fatal error
E_ALL 在 PHP 5.4+ 版本中同时包含 E_WARNING 和 E_ERROR（即对应 Warning 和 Fatal error），但注意：
• error_reporting(E_ALL) 只控制“是否报告”，不改变错误行为本身
• Fatal error 即使关闭 display_errors 也会终止脚本，只是不显示给用户
• Warning 默认不写日志，需显式开启 log_errors=On 才会落盘
生产环境务必关掉 display_errors，否则 Warning 可能泄露路径、配置等敏感信息。
为什么 try-catch 抓不住 Fatal error
根本原因是：PHP 的错误（Error）和异常（Exception）属于两套机制。
• Warning、Notice 等传统错误走 error_handler 流程
• Fatal error 属于编译/执行引擎级崩溃，不经过用户态错误处理链路
• PHP 7+ 引入了 EngineException 和 Error 类（继承自 Throwable），但仅覆盖部分 Fatal error 场景（如类型声明失败），并非全部
所以别指望 try-catch 挡住 call_undefined_function() —— 它连进入 try 块的机会都没有。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
