Composer安装symfony/mailer失败主因是PHP版本低于8.1或旧版Symfony组件冲突；SMTP不发信常因MAILER_DSN为空或DSN格式错误导致fallback至null transport；手动构建Mailer须用Transport::fromDsn()，Email附件需绝对路径；发信慢多由DNS或TLS握手引起，可通过DSN参数优化。
Composer安装symfony/mailer失败的常见原因
直接运行 composer require symfony/mailer 失败，大概率不是组件本身有问题，而是环境或依赖冲突。Symfony Mailer 从 v6.2 起要求 PHP ≥ 8.1，且强依赖 symfony/mime 和 symfony/service-contracts —— 如果项目里已有旧版 Symfony 组件（比如 v5.x 的 symfony/http-foundation），Composer 会因版本约束无法满足而中止安装。
- 检查 PHP 版本：
php -v，低于 8.1 就别硬试，先升级 PHP 或降级 Mailer（如用symfony/mailer:^5.4） - 运行
composer why-not symfony/mailer:^6.4查具体冲突包，比盲目删vendor有效得多 - 若项目用 Laravel，别单独装 Mailer：Laravel 9+ 已内置封装，直接配
MAIL_MAILER=smtp就行，额外 require 反而引发服务提供者重复注册
SMTP配置下Mailer不发信但也不报错
这是最让人抓狂的情况：调用 $mailer->send($email) 后页面正常返回，日志空空如也，邮箱却没收到任何东西。根本原因通常是传输器（Transport）未真正启用或被静默降级。
- 默认 Transport 是
sendmail，但很多本地开发环境没装 sendmail，symfony/mailer会自动 fallback 到 null transport（即“假装发了”，实际丢弃）—— 检查MAILER_DSN环境变量是否为空或拼错 - SMTP 配置必须带 scheme：
smtp://user:pass@smtp.example.com:587?encryption=tls，漏掉smtp://或写成smtp:都会导致 Transport 构建失败并静默退化 - 使用
symfony/mailgun-mailer等第三方 transport 时，确保已composer require symfony/mailgun-mailer，否则 DSN 解析到未知 scheme 也会 fallback 到 null
在非Symfony项目中手动构建Mailer实例
不走框架容器时，Mailer 本身轻量，但 Transport 和 Email 构造稍有门槛。核心是别绕过 TransportFactory 自己 new Transport 类——它负责处理 DSN 解析、加密协商和连接复用。
- 正确方式：用
Transport::fromDsn($_ENV['MAILER_DSN'])创建 Transport，再传给new Mailer() -
Symfony\Component\Mime\Email必须用 set* 方法链式调用，不能直接赋值属性；$email->to('a@b.c')->subject('Hi')是合法的，$email->to = 'a@b.c'会出错 - 附件路径必须是绝对路径，相对路径（如
./files/report.pdf）会被忽略——用__DIR__ . '/files/report.pdf'更安全
Mailer发信慢或超时的定位方法
发一封邮件卡 3–5 秒，通常不是代码问题，而是 DNS 或 TLS 握手环节被阻塞。Mailer 默认启用 DNS 缓存和连接池，但首次调用仍需完整握手。
- 加
?timeout=5到 DSN 末尾（如smtp://...?timeout=5），避免默认 30 秒等待拖垮响应 - 测试是否 DNS 导致：把 SMTP 域名换成 IP（如
smtp://user:pass@192.0.2.1:587），如果变快，说明本地 DNS 解析慢或污染 - 禁用 TLS 验证仅用于调试：
?verify_peer=0&verify_peer_name=0，但上线前必须删掉——生产环境跳过证书校验等于裸奔
Mailer 的 Transport 层抽象得很干净，但 DSN 字符串里的每个 query 参数都可能成为性能开关。改一个 ? 后面的值，效果可能比重写发送逻辑还明显。
