ThinkPHP中try-catch捕获不到Notice和Warning，因其属PHP错误而非异常；TP5.1+虽可转错为异，但需error_reporting开启对应级别且未被提前覆盖，常见坑点包括入口文件配置失效、CLI下$_SERVER不可用、Log::listen()中$context结构不稳定等。
ThinkPHP中try-catch为什么捕获不到Notice和Warning
因为PHP的E_NOTICE、E_WARNING属于错误（error），不是异常（exception），try-catch默认只捕获Exception及其子类。ThinkPHP 5.1+ 默认会把所有错误转为异常，但前提是error_reporting已开启对应级别，且未被入口文件外的配置提前覆盖。
常见踩坑点：
-
error_reporting(E_ALL ^ E_NOTICE)写在入口文件public/index.php里——无效，框架初始化前就执行完了，起不到作用 - CLI模式下（如队列任务）
$_SERVER不可用，但日志钩子里又直接访问$_SERVER['REQUEST_URI']，导致Notice报出后无法被捕获 - 调试模式关闭时，
Log::listen()仍会触发，但$context['exception']可能为null，直接instanceof判空不严谨
用Log::listen()提取异常详情必须检查$context结构
ThinkPHP的Log::listen()回调接收的$context数组内容不稳定：HTTP请求下有exception、trace等键；CLI下可能只有message和level，甚至exception字段根本不存在。
安全提取方式：
立即学习“PHP免费学习笔记（深入）”；
- 先判断
isset($context['exception'])，再做instanceof Exception - 不要硬取
$_SERVER['REQUEST_URI']，改用request()->url() ?? 'cli'（需确保request()可用）或兜底为空字符串 - 堆栈信息优先用
$e->getTraceAsString()，而不是直接读$context['trace']——后者在部分版本中是格式化后的字符串，也可能缺失
自定义异常类必须继承think\Exception而非原生Exception
ThinkPHP内置异常处理机制（如AppExceptionHandle）默认只识别think\Exception及其子类。若直接extends Exception，会导致异常被绕过框架处理器，降级为PHP默认错误页或500响应，且render()方法不生效。
正确写法示例：
namespace app\exception;
use think\Exception;
class ValidationException extends Exception
{
}
抛出时：throw new ValidationException('用户名不能为空');
配套动作：
- 在
app/exception_handle.php中注册该类到$ignoreException或$convertException（视TP版本而定） - 重写
render()方法时，用get_class($e) === ValidationException::class做类型判断，避免is_a($e, 'ValidationException')因命名空间问题失效
生产环境获取错误信息要绕开$_SERVER和debug_backtrace()
FastCGI缓存、Swoole协程、CLI子进程等场景下，$_SERVER字段不全或为空，debug_backtrace()可能被禁用或返回空数组。直接依赖它们提取上下文，会导致告警邮件内容残缺甚至PHP Warning。
可行替代方案：
- 用
think\Request实例的url()、method()、header('user-agent')代替$_SERVER直取 - 异常发生时，立即用
get_defined_vars()抓当前作用域变量（注意别包含大对象，防止内存溢出） - 记录日志时加
microtime(true)时间戳，比依赖date('c')更可靠
最易被忽略的一点：Log::listen()回调在CLI和HTTP共用同一份逻辑，但两者的运行上下文差异极大——没做分支适配的代码，上线后会在队列任务里静默丢弃关键错误信息。
