TP6的ExceptionHandler默认仅处理HTTP异常，命令行、队列等需手动捕获并调用report()；邮件通知应通过event('exception.reported')触发异步监听器发送，避免阻塞；ValidateException默认不进入ExceptionHandler，需启用fail_exception或主动抛异常。
ThinkPHP 6 的 ExceptionHandler 怎么接管所有未捕获异常
默认情况下，TP6 的 ExceptionHandler 只处理 HTTP 请求上下文中的异常，命令行（php think command）、队列任务、定时任务等场景会绕过它，直接抛出原始错误。必须手动在这些入口补上异常捕获逻辑。
实操建议：
- 在
app/exception/Handler.php的report()方法里统一调用邮件发送逻辑，而不是只在render()里做；render()仅负责响应渲染，report()才是「记录+通知」的正经位置 - 命令行入口（如
app/command/YourCommand.php）需手动 try/catch，并显式调用app()->make(\think\exception\Handle::class)->report($e) - 队列任务中，建议在基类
Job的handle()外层包一层 try/catch，避免异常被队列驱动吞掉
邮件通知该在 report() 还是单独起个监听器
直接写在 report() 最简单，但会拖慢请求响应——发邮件是同步阻塞操作。TP6 支持事件机制，更合理的方式是触发自定义事件，再由异步监听器处理邮件。
实操建议：
- 在
report()里只做轻量动作：event('exception.reported', $exception) - 新建监听器
app/listener/SendExceptionMail.php，监听exception.reported事件，内部用think\facade\Mail发送（注意配置好 SMTP 或第三方服务） - 若用 Redis 队列，可把邮件发送逻辑再投递到队列中执行，彻底解耦；否则至少加
if (app()->runningInConsole()) { ... }分流，避免命令行任务卡住
think\exception\ValidateException 为啥收不到邮件
验证异常（如 validate(['name' => ''])->check() 失败）默认被框架静默拦截，走的是 Validate 自己的错误返回路径，根本不会走到 ExceptionHandler。它不属于「未捕获异常」，而是「预期中的业务校验失败」。
实操建议：
- 需要对验证失败也发邮件？得在控制器或服务层主动 throw 新异常，例如
throw new \think\Exception('验证失败：' . $validate->getError(), 400) - 或者重写
Validate类，在failException模式下启用（配置'fail_exception' => true），这样验证不通过时会抛出ValidateException，才能被ExceptionHandler捕获 - 别依赖
ValidateException的默认行为去发告警邮件——它设计初衷就不是用来告警的
生产环境邮件发不出？检查这三处硬编码陷阱
本地能发，线上没反应，90% 是环境差异导致的配置或权限问题，不是代码逻辑错。
实操建议：
-
.env里确认MAIL_HOST、MAIL_USERNAME、MAIL_PASSWORD已正确填写，且没有空格或换行符（尤其密码含特殊字符时，要用引号包裹） - Linux 服务器上，检查是否禁用了
fsockopen或stream_socket_client（某些共享主机限制），可用php -r "var_dump(function_exists('fsockopen'));"快速验证 - TP6 默认使用
think\facade\Mail，但它底层依赖symfony/mailer，如果项目里手动替换了 Mailer 实现（比如用了topthink/think-swoole），可能绕过了原有配置，得查config/mail.php是否被覆盖
异常通知最怕“以为发了，其实没发”。建议第一次上线前，用 try/catch 包住邮件发送逻辑，把失败信息记到日志里，而不是只依赖成功回调。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
