TP5.1短信防轰炸核心是IP与手机号双维度独立限流：IP限流须在中间件层前置拦截，用Redis原子操作INCR+EXPIRE按真实IP计数；手机号频控须绑定业务标识key并确保Redis原子性，二者缓存key不可混用，且必须配置Nginx透传头与trusted_proxies才能获取真实IP。
TP5.1 实现短信防轰炸，核心不是堆砌多个 if 判断，而是让 IP 限流和手机号频控在同一个请求生命周期里互不干扰、各自生效，且不能被绕过。关键点在于：IP 维度必须前置到路由/中间件层，手机号维度必须绑定缓存原子操作，两者不能混用同一套缓存 key。
TP5.1 中间件里怎么写 IP 限流逻辑
别在控制器里做 IP 判断——太晚，攻击流量已经进来了。必须用中间件，在路由匹配后、控制器执行前拦截。
- 新建
app/middleware/IpRateLimit.php，在handle()方法里取$request->ip()，注意要配置'trusted_proxies' => ['*']才能拿到真实 IP（Nginx 反向代理时需透传X-Forwarded-For） - 用 Redis 做计数：
INCR ip:limit:{$_SERVER['REMOTE_ADDR']}，再EXPIRE设 60 秒 TTL，避免 key 持久堆积 - 阈值设为 60 次/分钟足够压制扫描器；但别设成 1 次/秒——用户切 WiFi 或移动网络重连会频繁触发误封
- 命中限流直接返回
json(['code'=>429,'msg'=>'请求过于频繁'])并exit，不要继续往下走
手机号频控为什么不能只靠 Redis 的 SETEX
只用 SETEX sms:send:138****1234 3600 1 是错的：并发高时多个请求同时读到 key 不存在，全部通过校验，导致超发。
- 必须用原子操作：
INCR sms:count:138****1234+EXPIRE sms:count:138****1234 3600，Redis 保证 INCR 和 EXPIRE 在同一连接中执行 - 读取后判断：
if ($count > 5) { // 拒绝发送 }，注意这个 5 是每小时上限，不是每次递增都重置 - 别用文件缓存驱动——TP5.1 默认 File 缓存多机部署下完全失效，生产环境必须切 Redis
- key 命名建议带业务标识：
sms:hourly:138****1234，避免和其他模块冲突
为什么 TP5.1 的 Request::ip() 有时拿不到真实 IP
不是框架 bug，是部署链路没配对。常见于 Nginx + PHP-FPM 架构下，$_SERVER['REMOTE_ADDR'] 只会显示 Nginx 的内网地址。
- 检查 Nginx 配置是否加了：
proxy_set_header X-Real-IP $remote_addr;和proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; - TP5.1 配置文件
config/app.php中确认'trusted_proxies' => ['127.0.0.1', '192.168.0.0/16']包含你的 Nginx 服务器网段 - 测试方法：在中间件里
dump($_SERVER['HTTP_X_FORWARDED_FOR'] ?? $_SERVER['REMOTE_ADDR'])，看输出是否为你本地公网 IP - 如果始终是 127.0.0.1，说明 Nginx 没透传头，或 PHP-FPM 的
fastcgi_param没转发
真正难的不是写几行限流代码，而是让 IP 和手机号两个维度的计数互不污染、不互相覆盖，且在高并发下依然准确。很多人卡在 Redis 原子性没处理好，或者 Nginx 头透传漏了一环，结果上线后发现“好像有限流，但还是被刷”。
