laravel限流需同时满足三个刚性条件：缓存驱动必须为redis（或memcached）、路由须显式绑定throttle中间件（api组默认启用但web组不自动生效）、限流键必须唯一标识请求主体；throttle:60,1中60是每分钟最大请求数、1是时间窗口分钟数，不支持原生秒级限流。
直接说结论：Laravel 限流不是加个 throttle 中间件就完事，真正生效依赖三个刚性条件——缓存驱动必须是 redis（或 memcached），路由必须显式绑定中间件（api 组默认不自动启用），且限流键（key）必须能唯一区分真实请求主体。漏掉任一，线上就等于没限。
throttle:60,1 的两个参数到底控制什么
第一个数字是「窗口内允许的最大请求数」，第二个是「时间窗口长度（单位：分钟）」，不是秒、不是小时，且只接受整数。比如 throttle:5,1 是每分钟最多 5 次；throttle:10,60 是每 60 分钟最多 10 次（即等效于每小时 10 次）。
常见误解：
-
throttle:5,60不是“每 60 秒 5 次”，而是“每 60 分钟 5 次” - Laravel 不支持原生秒级窗口（如 30 秒），想实现“每 30 秒 1 次”，得用
throttle:2,1+ 前端防抖兜底 - 未登录用户默认按 IP 限流，但前提是没配
auth中间件；一旦加了auth，又没登录，会因$request->user()为 null 导致by($request->user()->id)报错
为什么加了 throttle 中间件却完全不生效
最常踩的坑是缓存驱动配置错误或中间件挂载位置不对：
- 检查
config/cache.php中'default'是否指向redis；用array驱动时，多进程/多机器下计数器互不可见，限流形同虚设 -
throttle中间件默认只在api中间件组中注册，web路由不会触发——不能指望它自动覆盖所有接口 - 在
app/Http/Kernel.php的$middlewareGroups['web']里硬塞ThrottleRequests::class会静默失败，因为 web 组默认不初始化 session 和认证上下文 - Redis 连接失败时，Laravel 会悄悄退化为不限流，日志里通常不报错，只能靠监控响应头
X-RateLimit-Limit是否出现来反向验证
如何按设备指纹、API Key 或租户 ID 限流
默认按 IP 或用户 ID 太粗，CDN 后所有用户共用一个 IP，多个小程序共用一个后台账号也会互相干扰。必须重写限流键逻辑：
- 在
app/Providers/RouteServiceProvider.php的configureRateLimiting()方法里注册命名策略，例如按请求头X-API-Key：
RateLimiter::for('by-api-key', function (Request $request) {
$key = $request->header('X-API-Key');
return $key ? Limit::perMinute(100)->by($key) : Limit::perMinute(10)->by($request->ip());
});
- 确保
by()返回值是纯字符串，不能含空格、斜杠、换行等非法字符，否则缓存 key 构造失败，导致限流失效或误杀 - 路由中必须显式引用：
->middleware('throttle:by-api-key')，不能写成throttle:100,1这种硬编码，否则和策略脱节 - 调试时可用
php artisan tinker手动查缓存：Cache::get('rate_limit_by_api_key:abc123')（key 格式取决于你构造方式）
429 响应被忽略或返回格式不对怎么办
框架内部捕获 ThrottleRequestsException 并生成响应，你无法在控制器里 try/catch 它。要改返回内容，唯一正解是修改异常处理器：
- 在
app/Exceptions/Handler.php的render()方法中加判断：
if ($exception instanceof \Illuminate\Http\Exceptions\ThrottleRequestsException) {
return response()->json([
'message' => '请求过于频繁，请稍后再试',
'retry_after' => $exception->getHeaders()['Retry-After'] ?? 60,
], 429);
}
- 注意：如果返回 JSON，前端才能稳定解析；若混用 web 路由返回视图，可能因 session 状态不一致导致跳转异常
- 别忘了在响应中暴露限流头，否则前端拿不到
X-RateLimit-Remaining等信息：Access-Control-Expose-Headers: X-RateLimit-Limit, X-RateLimit-Remaining, Retry-After
真正容易被忽略的是 Redis 可用性与限流键设计的耦合性——它不像日志或数据库那样出错就报异常，而是在沉默中彻底放弃限流。上线前务必用压测工具模拟并发，盯着响应头和缓存 key 变化，而不是只看中间件有没有加。
