因为PHP默认同步发送邮件会阻塞HTTP请求，导致用户等待；应改用命令模式封装任务并投递至Redis或RabbitMQ队列，由独立消费者异步处理，同时控制重试、内存和时效性。
为什么直接在Web请求中发邮件会卡住用户？
PHP默认以同步方式执行mail()或SMTP发送，一旦网络延迟、邮箱服务器响应慢，整个HTTP请求就会阻塞，用户看到白屏或超时。这不是代码写得不好，而是架构错配——邮件属于“可延后”的业务动作，不该和实时响应耦合。
真正要做的，是把「构造邮件内容→选择收件人→触发发送」这个过程封装成一个可序列化的任务对象，丢进消息队列（如Redis List、RabbitMQ、Beanstalkd），由独立的消费者进程异步处理。
关键点：
• 不要在$_POST处理逻辑里调用sendMail()
• 每封邮件任务必须能被serialize()且不含资源句柄（如resource、Closure）
• 队列消费者需单独运行，不能依赖Web服务器生命周期（例如用php artisan queue:work或自定义php worker.php）
怎么用命令模式封装邮件任务？
命令模式在这里不是为了炫技，而是为了解耦「谁发起」和「谁执行」。每个邮件任务应是一个轻量PHP类，实现统一接口，比如MailCommand：
立即学习“PHP免费学习笔记（深入）”；
interface MailCommand
{
public function execute(): void;
public function toArray(): array; // 用于序列化入队
public static function fromArray(array $data): self; // 用于反序列化出队
}
示例具体实现：
• 类名用业务语义命名，如WelcomeEmailCommand或PasswordResetCommand
• 构造函数只接收原始数据（$userId, $templateId等），不传Mailer实例或DB连接
• execute()里才查库、渲染模板、调用PHPMailer或symfony/mailer
• 必须检查$this->userId是否存在，避免队列里存了已删除用户的ID导致静默失败
选Redis还是RabbitMQ做队列？
取决于你的部署复杂度和可靠性要求：
• Redis（List + BLPOP）适合中小项目：
– 用LPUSH mail_queue推任务，BLPOP mail_queue 0阻塞取任务
– 优势是无需额外服务，PHP原生ext-redis支持好
– 劣势是无ACK机制，消费者崩溃会导致任务丢失；需自己加重试字段（如attempts）和死信逻辑
• RabbitMQ适合需要可靠投递的场景：
– 必须开启durable队列 + delivery_mode=2 + 手动ack
– PHP端推荐用php-amqplib，别用过时的ext-amqp
– 注意设置prefetch_count=1，防止一个慢任务堵住整个消费者
无论哪种，都不要在任务体里写sleep(1)或usleep()做重试——交给队列本身的重入机制或外部调度器（如Cron触发重试扫描）
消费者进程怎么避免内存泄漏和无限重试？
一个跑着跑着就吃光内存的消费者，比不发邮件还糟。核心控制点有三个：
• 单次循环必须gc_collect_cycles()，尤其用了Twig或Smarty渲染模板后
• 任务执行加try/catch，捕获Exception和Error（PHP 7+），记录完整堆栈到日志，然后continue而非die
• 设置最大重试次数（如3次），超过后把原始toArray()数据转存到failed_mail_log表或S3，人工介入
启动脚本建议带内存限制：php -d memory_limit=128M worker.php
并配合Supervisor配置autorestart=true和startsecs=5，确保异常退出后快速拉起新进程
最常被忽略的是：队列里的任务时间戳没校验。如果某条任务卡在队列里超过24小时，再执行可能已失效（如密码重置链接过期），消费者应主动跳过而非硬发
