laravel 11.x 无官方认定的速率限制绕过漏洞，问题多源于配置错误或使用不当：需确保 auth:sanctum 在 throttle 前执行、限流必须用 redis 驱动、自定义策略须校验 key 合法性、禁用空限流策略。
Laravel 11.x 本身不存官方认定的“速率限制绕过漏洞”。框架内置的 throttle 机制和 RateLimiter 是安全可靠的，问题几乎总是出在配置错误、使用不当或环境缺失，而非限流逻辑本身被攻破。
真正需要防范的，是开发者无意中留下的“可绕过路径”。以下是关键处理方向：
明确限流作用域，避免认证与限流顺序错位
限流中间件依赖准确的识别依据（如用户 ID 或 IP）。若 auth:sanctum 没在 throttle 前执行，系统就无法拿到登录态，自动退化为按 IP 限流——这会让多个真实用户共用一个配额，也使攻击者可通过代理轮换 IP 绕过。
- 确保 API 路由中间件顺序为：
middleware(['auth:sanctum', 'throttle:60,1']) - 不要写成
['throttle:60,1', 'auth:sanctum']，否则Auth::id()为空，key 变成$request->ip()。
使用 Redis 驱动，禁用文件或数据库缓存做限流
throttle 底层依赖 RateLimiter，而它默认走 cache.default 配置。若生产环境仍用 file 或 database 缓存驱动：
- 并发下计数不准（无原子操作）
- TTL 不精确，导致限流失效或误封
- 无法支撑高吞吐场景，间接形成“事实绕过”
✅ 正确做法：
在 .env 中强制指定限流专用缓存驱动：
CACHE_STORE=redis RATE_LIMITER_CACHE=redis
并在 config/cache.php 中确保 limiter 键指向 Redis 连接。
自定义策略必须校验 key 的合法性
当你用 by($request->user()->id) 或 by($request->bearerToken()) 生成限流 key 时，若未判断 $request->user() 是否存在、或 token 是否为空，by(null) 会生成形如 rate_limit:api:null 的固定 key，所有未登录请求都挤在同一个桶里——表面有限流，实则形同虚设。
✅ 推荐写法（在 RouteServiceProvider::configureRateLimiting() 中）：
RateLimiter::for('api_by_user', function (Request $request) {
$key = $request->user()
? 'user_'. $request->user()->id
: 'ip_'. $request->ip();
return $request->user()
? Limit::perMinute(60)->by($key)
: Limit::perMinute(10)->by($key);
});
主动清理异常 key，防止恶意刷 key 耗尽缓存
攻击者可能构造大量非法 user ID 或随机 token，触发 RateLimiter::attempt('send-message:'.$id, ...) 生成海量 key，撑爆 Redis 内存或拖慢查询。
✅ 应对措施：
- 对高频操作 key 做标准化（如只允许数字 ID，拒绝字母/符号）
- 在关键入口加前置校验：
if (!is_numeric($id) || $id - 定期用
cache()->getPrefix()+Redis::keys()扫描异常前缀 key（生产慎用），或通过监控告警突增 key 数量
不要用 throttle:api 这类空策略占位
Laravel 11 默认注册了 throttle:api，但其策略体为空（return null;）。若路由写了 middleware('throttle:api')，等于没限流。
✅ 务必显式注册并使用自定义策略名，例如：
// RouteServiceProvider.php
RateLimiter::for('strict_api', fn () => Limit::perMinute(30));
再在路由中调用 middleware('throttle:strict_api')。
不复杂但容易忽略
