thinkphp中error_reporting失效是因为框架接管错误处理，真正起效的是app_debug和error_level配置；app_debug控制调试模式开关，error_level决定哪些错误转为异常，默认已屏蔽e_user_notice等提示级错误。
为什么 error_reporting 在 ThinkPHP 里经常失效
因为 ThinkPHP 默认接管了 PHP 的错误处理流程，直接改 error_reporting(E_ALL) 或 ini_set('error_reporting', 0) 基本没用——它早被框架的 think\exception\Handle 和底层 set_error_handler 拦截了。
真正起作用的是框架自身的错误级别开关，不是 PHP 原生配置。
- ThinkPHP 6+ 使用
app_debug控制是否开启调试模式，该配置直接影响错误是否上报、是否显示、是否记录 -
app_debug = false时，E_NOTICE和E_USER_NOTICE默认被静默丢弃，连日志都不写 - 即使
app_debug = true，框架也只把E_ERROR、E_PARSE、E_COMPILE_ERROR等致命错误交给异常处理器，其余靠trigger_error发出的提示级错误会被过滤
屏蔽 E_USER_NOTICE 的两种可靠方式
最常见需求是关掉自己写的 trigger_error('xxx', E_USER_NOTICE)，又不想关掉 E_WARNING 或更高级别错误。
- 在
app/exception/Handler.php的report方法里加判断：
public function report(Throwable $e): bool
{
if ($e instanceof \ErrorException && $e->getSeverity() === E_USER_NOTICE) {
return true; // 返回 true 表示已处理，不再上报
}
return parent::report($e);
}
- 或者在
app/common.php或入口文件中，重置错误处理器前先拦截：
set_error_handler(function ($level, $message, $file, $line) {
if ($level === E_USER_NOTICE) {
return true; // 不抛出异常，也不记录
}
return false; // 交还给框架默认处理器
});
注意：第二种方式要确保在框架初始化前执行，否则会被覆盖。
config/app.php 里的 error_level 到底管什么
这个配置项只影响「错误转异常」的阈值，不是全局过滤器。它决定哪些错误等级会触发 ErrorException 抛出，进而进入异常处理流程。
- 默认值是
E_ALL & ~E_NOTICE & ~E_DEPRECATED & ~E_USER_NOTICE & ~E_USER_DEPRECATED - 如果把它改成
E_ALL，那E_NOTICE也会变成异常，反而更容易被记录或显示——和你想要的“屏蔽”效果相反 - 想静默某类错误，不能调高
error_level，而要降低它，比如去掉E_USER_NOTICE对应的位
所以真要靠配置控制，得手动写个掩码：E_ALL & ~E_USER_NOTICE，而不是依赖默认值。
日志里还看到 E_USER_NOTICE？检查中间件和钩子
有些第三方扩展、自定义中间件或事件监听器（如 AppInit 钩子）会绕过主错误处理器，直接调用 Log::notice() 或 error_log() 输出内容，看起来像错误但其实不是 PHP 错误。
- 搜索项目中所有
trigger_error、Log::notice、Log::info调用点 - 检查
app/middleware.php是否有未捕获的中间件抛出 notice 级提示 - 确认
think\log\driver\File配置里level没有设成['*']，否则所有日志级别都会写入
这类输出不受 error_level 或 app_debug 控制，得逐个定位、改调用或加条件判断。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
