应使用异步队列处理邮件发送——因同步调用mail()或PHPMailer会阻塞HTTP请求，受SMTP连接、DNS查询、TLS握手及远程响应延迟影响，且共享主机常限频；需用Redis队列配合supervisor托管worker，确保消费可追溯、失败可重试、积压可监控。
PHP邮件发送卡在mail()或PHPMailer::send()上，不是代码写错了，而是你让它同步执行了——用户注册、找回密码这类操作本不该等几秒收件箱确认。
为什么直接调用mail()或PHPMailer会拖慢页面
SMTP连接建立、DNS查询、TLS握手、远程服务器响应延迟，每一环都可能耗时500ms以上；而PHP默认是阻塞式执行，mail()返回前整个HTTP请求就挂在那里。更糟的是，某些共享主机限制mail()函数每分钟调用次数，一并发就失败。
常见错误现象包括：Maximum execution time of 30 seconds exceeded、用户点击注册按钮后白屏数秒、Nginx报upstream timed out。
- 本地
sendmail路径配置错误（如sendmail_path指向不存在的二进制）会导致静默失败 - 未启用
opcache或curl扩展时，第三方邮件SDK加载变慢 - 使用
localhost作为SMTPHOST但未运行Postfix/Sendmail服务，连接直接超时
QUEUE_CONNECTION=redis配好了，但php artisan queue:work不消费任务
这通常不是Laravel队列本身的问题，而是环境或权限链断裂。Redis连接正常、任务写入queues:default列表成功，但Worker没起来或起起来了却读不到任务。
立即学习“PHP免费学习笔记（深入）”；
检查要点：
- 确认
php artisan queue:work是在后台常驻运行（不是手动敲一次就退出），推荐用supervisor托管，而非nohup临时跑 - Worker进程用户（如
www-data）必须有权限读取.env和config/queue.php，尤其注意文件属主和SELinux上下文 - 如果用Redis集群或哨兵模式，
REDIS_CLIENT=phpredis且redis://连接串中不能含password@格式，需改用auth参数显式传入 -
QUEUE_FAILED_JOB_DATABASE表缺失或failed_jobs迁移未执行，会导致任务失败后无法重试，Worker反复卡死
不用框架，手写数据库队列怎么防重复消费和任务堆积
用email_queue表做队列最轻量，但也最容易出问题：cron脚本每分钟拉一次，但某次发送慢了2分钟，下次又启动一个实例，同一封邮件就被发两遍。
关键控制点：
- 状态字段必须用
TINYINT而非VARCHAR，值定义为：0=待处理、1=发送中、2=成功、3=失败；更新时用WHERE status = 0 LIMIT 1+FOR UPDATE事务锁行 - cron命令要加锁，例如：
if [ ! -f /tmp/email_queue.lock ]; then touch /tmp/email_queue.lock && php send_queue.php && rm /tmp/email_queue.lock; fi - 单次最多处理50条（
SELECT ... LIMIT 50），避免脚本超时；失败任务设retry_count字段，超过3次自动标为status=3并记录error_message - 定期清理：每天凌晨删
status IN (2,3) AND updated_at 的旧记录
用exec()后台跑脚本看似简单，为什么线上禁用
因为exec("php send.php > /dev/null 2>&1 &")这种写法绕过了所有PHP进程管理机制，根本不可控。
真实踩坑场景：
- 脚本崩溃后无日志，
/dev/null吞掉全部错误输出，你连哪行报错都不知道 - 并发高时，系统fork大量子进程，
ulimit -u触顶导致Apache/Nginx子进程创建失败 - 参数未过滤，用户提交邮箱含
$(rm -rf /)会被shell执行（哪怕只是escapeshellarg()也挡不住复杂注入） - 没有内存限制，一封带附件的邮件可能吃光512MB内存，触发OOM Killer干掉MySQL
真正该关注的不是“怎么让它快”，而是“怎么让它稳”——队列的可靠性不在推送快，而在消费可追溯、失败可重试、积压可监控。别为了省事跳过failed_jobs表或Redis的RPOPLPUSH原子操作，那些地方才是半夜告警的源头。
