Laravel 9 已弃用 SwiftMailer，转而使用 Symfony Mailer；该组件默认不提供 Mail::failures() 这类全局失败收件人追踪机制，需通过异常捕获与自定义逻辑实现失败地址识别。
如何在 laravel 9 中捕获邮件发送失败的收件人列表：laravel 9 已弃用 swiftmailer，转而使用 symfony mailer；该组件默认不提供 `mail::failures()` 这类全局失败收件人追踪机制，需通过异常捕获与自定义逻辑实现失败地址识别。
Symfony Mailer 的设计哲学是：只要邮件成功提交至传输层（如 SMTP 服务器或 SendGrid 等第三方服务），即视为“发送成功”。这意味着——即使后续因收件人邮箱不存在、被拒收或退信导致实际投递失败，这些信息也不会由 Symfony Mailer 主动暴露给应用层，因为它们发生在传输层之后，超出了框架的控制范围。
因此，Laravel 9 中无法像旧版那样调用 Mail::failures() 获取失败邮箱列表。取而代之的是，你只能在邮件提交阶段（即 send() 调用时）捕获传输异常，从而识别出因网络错误、认证失败、连接超时或 SMTP 拒绝（例如一次性拒绝多个无效邮箱）而导致的即时失败。
PHP中文网提供Laravel 13.2.0版本下载，Laravel框架 是基于 PHP 8.3+ 的高性能框架，官方推荐通过 Composer 安装。它内置 AI SDK、JSON:API Resources 及原生向量搜索，支持属性驱动开发与队列路由，大幅提升开发效率。相比旧版，13.2.0 优化了缓存 TTL 管理与实时通信，无需 Redis 即可横向扩展。作为现代 Web 开发首选，它兼顾安全与极速体验，助您快速构建企业级应用。
✅ 正确做法：捕获 TransportExceptionInterface
你需要显式包裹邮件发送逻辑，并监听 Symfony 提供的底层异常：
use Illuminate\Support\Facades\Mail;
use Symfony\Component\Mailer\Exception\TransportExceptionInterface;
use Symfony\Component\Mime\Email;
// 构建邮件（支持单收件人或多收件人）
$email = (new Email())
->to('valid@example.com')
->to('invalid@nonexistent.domain') // 可能触发 SMTP 拒绝
->subject('Test Message')
->text('Hello world!');
try {
Mail::send($email);
// ✅ 发送成功：邮件已被传输层接收（但不代表最终送达）
} catch (TransportExceptionInterface $e) {
// ❌ 传输失败：获取原始异常信息用于诊断
\Log::error('Email transport failed: ' . $e->getMessage());
// 注意：此处无法精确知道「哪个收件人」失败 ——
// SMTP 通常以整体方式拒绝整封邮件（尤其当含多个 to/cc 地址时）
}
⚠️ 关键注意事项
- 无内置逐收件人失败反馈：Symfony Mailer 不提供类似 SwiftMailer 的 getFailedRecipients() 方法；TransportExceptionInterface 是粗粒度异常，不携带具体失败邮箱列表。
- 多收件人场景下的局限性：若一封邮件含多个 to() 地址，而 SMTP 服务器因其中某个地址无效而拒绝整封邮件，你无法仅凭异常得知是哪一个——需拆分为单收件人邮件逐一发送，才能精准定位失败地址。
-
推荐增强方案（如需精确失败追踪）：
- 使用 Bcc 或专用日志通道记录所有待发地址；
- 对每个收件人单独构造并发送邮件（牺牲性能换取可追溯性）；
- 集成第三方邮件服务（如 Mailgun、SendGrid）提供的Webhook 回调或事件 API，监听 failed, bounced, dropped 等真实投递状态；
- 启用 Laravel 的 Mail Log Driver 进行调试，但仅限开发环境。
✅ 总结
Laravel 9 中不再支持 Mail::failures()，这是 Symfony Mailer 架构演进的必然结果。开发者应转变思路：从“事后查询失败列表”，转向“事前预防 + 事中异常处理 + 事后异步监控”。真正可靠的失败收件人识别，依赖于传输层日志、第三方服务商回调或主动分拆发送策略，而非框架原生 API。
