php致命错误无法用try/catch拦截，需用register_shutdown_function()配合Error_get_last()捕获并记录；set_error_handler()仅处理非致命错误；typeerror等异常在php 7+可catch，但需确保其发生在try块内。
PHP 脚本被 E_ERROR 或致命错误直接终止怎么办
PHP 遇到未捕获的 E_ERROR、E_PARSE、E_COMPILE_ERROR 等致命错误时，会立刻停止执行，无法用 try/catch 拦截。这不是异常，是解析或运行期的硬性中断。
真正能兜底的只有 set_error_handler() + register_shutdown_function() 组合：
-
set_error_handler()可捕获E_WARNING、E_NOTICE等非致命错误，但对E_ERROR无效 -
register_shutdown_function()在脚本结束（无论正常退出还是崩溃）时强制触发，配合error_get_last()才能捞到致命错误信息 - 注意：
register_shutdown_function()本身不能阻止脚本终止，只能做最后记录或清理
用 try/catch 拦不住 Fatal error: Uncaught TypeError？
PHP 7+ 的 TypeError、ParseError、ArgumentCountError 是异常（Throwable 子类），理论上可被 try/catch 捕获。但实际中常漏掉两类场景：
- 函数签名不匹配发生在函数调用前（如参数类型声明写错），PHP 在编译阶段就报
ParseError，根本进不了try块 - 错误发生在
include/require加载的文件里，且该文件本身有语法错误，此时抛出的是ParseError，但若require写在try外，照样崩 - 正确姿势：把可能出问题的
require、动态调用、反射操作全包进try，并统一catch (Throwable $e)
为什么 error_reporting(0) 不等于“不中断”
error_reporting(0) 只是关闭错误输出和日志记录，它完全不影响错误是否发生、是否中断脚本。一个 E_ERROR 仍会让脚本戛然而止，只是你什么也看不见。
立即学习“PHP免费学习笔记（深入）”；
常见误用：
- 线上环境设了
error_reporting(0)就以为高枕无忧 → 实际错误照崩，只是没日志，排查更难 - 和
ini_set('display_errors', '0')混淆 → 后者只控制是否输出到页面，不影响执行流 - 真正要降级影响，得靠
set_error_handler()把警告转成异常再处理，或用@抑制（慎用，会掩盖真问题）
生产环境必须检查的三个配置项
光写代码不够，PHP 运行时配置决定错误能否被感知和响应：
-
display_errors = Off：必须关，防止敏感信息泄漏；但它和脚本中断无关 -
log_errors = On：确保所有错误（包括致命错误）都写入error_log，否则register_shutdown_function()捞不到上下文 -
error_log = /path/to/php-error.log：明确指定路径，避免写进 Web 服务器日志导致权限或轮转混乱
这些配置一旦配错，shutdown 函数里调用 error_get_last() 可能返回空，或者错误信息写到了没人看的地方。