thinkphp无内置邮件频次限制，必须在业务层用redis校验用户/ip+时间窗口计数，throttle中间件仅限http请求，无法控制mail::send()内部调用。
ThinkPHP 本身不提供「邮件发送频次限制」的内置机制，think\facade\Mail 只负责调用底层邮件驱动（如 SMTP），完全不感知发送频率。所谓“防邮件轰炸”，必须在业务逻辑层手动控制，否则哪怕配置了 throttle 中间件，它也只拦 HTTP 请求，拦不住你代码里循环调用 Mail::send()。
为什么直接用 throttle 中间件无效
限流中间件（如 ThrottleRequests 或第三方 think-throttle）作用于 HTTP 请求生命周期，而邮件发送是 PHP 后端内部行为，和请求入口无关。常见错误是：加了 ->middleware('throttle:5,1')，但用户仍能通过一次 API 调用触发发 100 封邮件——因为中间件只限制「调用接口的次数」，不限制「接口内部发多少封邮件」。
- 中间件生效前提是路由绑定了控制器方法；闭包路由、资源路由未显式绑定时，
throttle根本不执行 - 即使中间件生效，它只控制「每分钟最多被调用 5 次」，不代表这 5 次里每次只能发 1 封邮件
- 邮件发送逻辑若写在
index方法里且无额外判断，第 1 次调用就可能批量发信
如何在业务代码中做发送频次控制
必须在调用 Mail::send() 前插入校验逻辑，核心是「按用户/手机号/IP + 时间窗口」计数。推荐用 Redis，避免文件缓存并发失效问题。
- 使用
Cache::store('redis')->inc($key)自增计数，再用expire($key, 60)设置 60 秒过期 - 键名建议含维度信息，例如：
mail:uid:1001:20260402（用户 ID + 日期）或mail:ip:192.168.1.100:reset_at_1743628860（IP + 时间戳） - 注意不要用
$request->ip()直接作为限流依据——Nginx 后需取$request->header('X-Real-IP', $request->ip()) - 校验失败时，应抛出异常或返回明确错误，而非静默跳过，否则前端无法感知限制已触发
config/mail.php 配置不能替代频次控制
很多人误以为改 config/mail.php 里的 timeout 或加 retry_times 能防轰炸，其实这些只影响单次连接/重试行为，和「单位时间发多少封」完全无关。SMTP 配置正确与否决定邮件能否发出，但不构成任何频率约束。
-
MAIL_ENCRYPTION设错会导致连接失败，但失败后重试仍是新请求，不计入限流 - QQ/163 邮箱要求用授权码，填错密码只会报
Authentication failed，不会触发限流逻辑 - 若用
file缓存驱动存限流数据，在高并发下 key 冲突或覆盖概率极高，务必切到redis或memcached
真正起效的限流永远在业务代码里那几行 if (Cache::get($key) > 5) { throw new Exception('今日发送已达上限'); } ——中间件、配置、驱动都只是工具，控制权始终在你写的逻辑中。漏掉这一层，再严密的反向代理层限流也拦不住一封恶意构造的请求。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
