thinkphp无法捕获parse/compile error、fatal error（如内存耗尽、类未找到）、php启动期扩展崩溃、exit()/die()及e_error等错误，因其绕过set_error_handler；需用register_shutdown_function+error_get_last()补漏，并配置log_errors确保底层日志记录。
ThinkPHP 的异常捕获并不“全”——它默认只接管了 Exception 和 Error（PHP 7+）的顶层抛出，但大量实际运行中的错误类型（比如未定义变量、语法错误、致命错误早期阶段、扩展层崩溃）根本不会走到框架的异常处理流程里。
哪些错误 ThinkPHP 根本捕获不到
框架的 think\exception\Handle 类只在 register() 中通过 set_exception_handler 和 set_error_handler 挂钩，但它对以下情况完全无能为力：
-
Parse error、Compile error：PHP 解析或编译失败时，脚本根本没执行到框架初始化，register()都没被调用 -
Fatal error（如Allowed memory size exhausted、Class not found在new之前）：部分 fatal error 不触发set_error_handler，尤其在 autoloader 失败或内存超限时 - PHP 启动阶段扩展崩溃（如 opcache segfault、xdebug 配置错误）：进程直接退出，无 PHP 层干预机会
-
exit()/die()调用：属于主动终止，不是异常，框架不拦截
set_error_handler 覆盖不了的 PHP 错误级别
ThinkPHP 的错误处理器默认忽略 E_ERROR、E_PARSE、E_CORE_ERROR、E_COMPILE_ERROR、E_USER_ERROR 等——这些错误会绕过 set_error_handler 直接中止脚本。你看到的“白屏”或“500”，往往就是这类错误。
即使你手动在 App::init() 前加 error_reporting(E_ALL)，也改变不了这个限制。PHP 的设计如此，不是框架能绕过的。
立即学习“PHP免费学习笔记（深入）”；
验证方式很简单：
php
// 在入口文件 public/index.php 最开头插入：
error_reporting(0);
trigger_error('This shows up', E_USER_NOTICE); // ✅ 被 TP 捕获
trigger_error('This does NOT show up', E_USER_ERROR); // ❌ 白屏，TP 无响应
自定义 register_shutdown_function 补漏是唯一可行方案
要捕获 Fatal error 和部分解析错误的残留信息，必须靠 register_shutdown_function + error_get_last() 组合。ThinkPHP 默认不启用这个，需手动补上：
- 放在
public/index.php框架加载前（即require __DIR__.'/../thinkphp/start.php';之前） - 注意避免重复注册（TP 6.1+ 的
think\initializer\Error已内置该逻辑，但仅限 CLI 场景；Web 场景仍需自行加固） - 日志写入必须用同步方式（如
file_put_contents），不能依赖 TP 的日志驱动（此时容器可能未初始化）
php
register_shutdown_function(function () {
if ($error = error_get_last()) {
$type = $error['type'] ?? 0;
if (in_array($type, [E_ERROR, E_PARSE, E_CORE_ERROR, E_COMPILE_ERROR, E_USER_ERROR])) {
$msg = sprintf("[%s] %s in %s on line %d",
$error['type'], $error['message'], $error['file'], $error['line']);
error_log($msg . PHP_EOL, 3, __DIR__ . '/../runtime/logs/fatal-' . date('Y-m-d') . '.log');
}
}
});
配置 display_errors 和 log_errors 是底层兜底
别迷信框架异常处理器。生产环境必须关掉 display_errors（防止敏感路径泄露），但要确保 log_errors = On 且 error_log 指向可写文件。这是 PHP 自身最可靠、最底层的错误记录通道，比任何框架逻辑都优先。
常见疏漏点：
- Nginx + PHP-FPM 下，
php.ini的error_log可能被 FPM 的php_admin_value[error_log]覆盖，得查 FPM pool 配置 - 某些 Docker 镜像默认把
error_log指向/dev/stderr，日志会进容器 stdout，而非文件 - TP 的
app_debug = true只影响框架层渲染，不影响 PHP 是否记录 fatal error
真正关键的不是“TP 能捕获多少”，而是你有没有在 PHP 运行时、Web 服务器、容器/系统三个层面都留了可观测出口。框架只是中间一环，太依赖它，出问题时连错误在哪一层都定位不了。
