真正生效的关键是配置redis缓存驱动并自定义限流键：需设cache_driver=redis，用x-device-id等业务标识替代ip，通过ratelimiter::for()注册命名策略，确保键名唯一稳定且与风控目标对齐。
直接用 throttle 中间件就能防基础爬虫，但默认按 IP 或用户 ID 限流在 CDN、NAT、多端共号场景下会完全失效——不改限流键（key），等于没设门槛。
throttle 中间件怎么配才真正生效
关键不是加不加中间件，而是缓存驱动是否撑得住。Laravel 的 ThrottleRequests 默认走 CACHE_DRIVER，如果配置的是 array，多 worker 进程下计数器互不可见，限流形同虚设。
- 检查
.env：确保CACHE_DRIVER=redis或memcached，不要用file或array - 确认 Redis 连通：运行
php artisan tinker后执行cache()->store('redis')->put('test', 'ok', 10)，能写入才算 OK -
路由里写法要明确：比如
->middleware('throttle:10,1')表示每分钟最多 10 次，1是分钟单位，不能写成60 - 若用
by=id，必须确保请求已通过认证中间件（如auth:sanctum），否则$request->user()为 null，降级为按 IP 限流却不报错
为什么爬虫绕过了 throttle：IP 不唯一是主因
CDN 回源、公司出口 NAT、云服务商负载均衡都会让成百上千真实用户共享一个 $request->ip()。此时按 IP 限流要么误杀大量正常用户，要么对爬虫毫无约束力。
- 优先从请求头取真实 IP：
$request->header('X-Real-IP') ?: $request->header('X-Forwarded-For')，但需 Nginx 配置proxy_set_header X-Real-IP $remote_addr; - 更可靠的是业务层标识：App 端传
X-Device-ID，小程序带X-OpenID，后台接口强制带X-Tenant-ID - 自定义 key 必须是纯字符串：避免空格、斜杠、换行；建议用
str_slug($value)或preg_replace('/[^a-zA-Z0-9_\-]/', '', $value)过滤
自定义限流策略的两种实操路径
一种轻量、一种可控，别混着用。
- 用
RateLimiter::for()注册命名策略（推荐）：在AppServiceProvider::boot()里注册，例如：RateLimiter::for('api-by-device', function (Request $request) { return Limit::perMinute(30)->by($request->header('X-Device-ID')); });然后路由写->middleware('throttle:api-by-device') - 继承
ThrottleRequests写中间件（需精细控制时）：重写resolveRequestSignature()，返回值就是缓存 key；注意该中间件必须注册到$routeMiddleware，不能放$middlewareGroups里 - 别漏掉响应头：Laravel 默认返回
X-RateLimit-Limit和X-RateLimit-Remaining，前端或监控可依赖；若自定义响应（如 JSON 错误），需手动加Retry-After头
RateLimiter::attempt() 适合防单点爆刷
比如登录页、短信发送、密码重置这些“一次成功即终止”的动作，比全局 throttle 更精准，且自带原子性。
- 键名必须唯一且稳定：例如
"login:{$request->ip()}"或"sms:{$phone}"，不能含动态时间戳 - 调用后立刻判断返回值：
if (! RateLimiter::attempt($key, 5, 60)) { return response(...)->setStatusCode(429); } - 它内部自动处理
INCR+EXPIRE，但前提是缓存驱动支持原子操作（Redis 支持，File/Array 不支持） - 调试时可用
cache()->get($key)查当前计数，但生产环境别留这种 debug 代码
最常被忽略的是：限流键的业务语义必须和风控目标对齐。用设备 ID 限流却没校验设备合法性，用 API Key 却没做 Key 存活检查——限流逻辑再严密，上游身份已经失守，就只是纸糊的门。
