Laravel速率限制？请求限制如何设置？

煙雲

发布时间：2025-09-02 18:19:01

769人浏览过

来源于php中文网

原创

Laravel速率限制通过throttle中间件和RateLimiter门面实现，基于缓存系统为不同用户、IP或API端点设置请求阈值，防止滥用并保护服务器资源。

laravel速率限制？请求限制如何设置？

Laravel的速率限制（Rate Limiting）功能，说白了，就是给你的应用设一道“门禁”，控制在一定时间段内，某个用户、某个IP或者某个API密钥能向你的服务器发送多少次请求。这玩意儿可太重要了，它能有效防止恶意刷接口、DDoS攻击，或者仅仅是避免你的API被过度调用，导致服务器资源耗尽。设置起来其实不复杂，主要通过路由中间件或者更灵活的

RateLimiter

Facade来搞定。

解决方案

要设置Laravel的请求限制，我们通常有两种主要途径，各有侧重：

1. 使用路由中间件 (Route Middleware) 进行全局或分组限制

这是最常见也最直接的方式。Laravel提供了一个开箱即用的

throttle

中间件。

首先，你可以在

app/Providers/RouteServiceProvider.php

文件的

configureRateLimiting

方法中定义你的速率限制器。这是我个人比较推荐的做法，因为它把所有的限制策略集中管理起来，清晰明了。

use Illuminate\Cache\RateLimiting\Limit;
use Illuminate\Support\Facades\RateLimiter;

/**
 * Configure the application's rate limiters.
 *
 * @return void
 */
protected function configureRateLimiting()
{
    RateLimiter::for('api', function (Request $request) {
        // 针对已认证用户，允许每分钟100次请求
        // 如果是未认证用户，则按IP每分钟60次
        return $request->user()
            ? Limit::perMinute(100)->by($request->user()->id)
            : Limit::perMinute(60)->by($request->ip());
    });

    RateLimiter::for('web', function (Request $request) {
        // 网页端，通常限制宽松些，或者只限制特定操作
        return Limit::perMinute(1000); // 宽松示例
    });

    // 针对一个特定的上传功能，比如图片上传，限制更严格
    RateLimiter::for('uploads', function (Request $request) {
        return Limit::perMinute(5)->by($request->user()->id ?: $request->ip());
    });
}

定义好限制器后，你就可以在路由中应用它们了：

// 应用到整个API路由组
Route::middleware(['api', 'throttle:api'])->group(function () {
    Route::get('/user', function () {
        // ...
    });
});

// 应用到特定路由，使用自定义的限制器名称
Route::post('/upload-image', [ImageController::class, 'upload'])
    ->middleware('throttle:uploads');

// 你也可以直接在路由中定义简单的限制规则，不依赖预设的限制器
// 例如：每分钟60次请求，每秒1次请求
Route::get('/some-endpoint', function () {
    // ...
})->middleware('throttle:60,1');

这里的

throttle:60,1

表示允许每分钟60次请求。

throttle:rate_limit_name

则会使用你在

configureRateLimiting

中定义的那个限制器。

2. 使用

RateLimiter

Facade 进行更精细的控制

有时候，你可能需要在代码的某个特定逻辑点进行速率限制，而不是整个路由。

RateLimiter

Facade就派上用场了，它提供了更底层的控制能力。

比如，你有一个发送短信验证码的功能，你可能不希望用户在短时间内频繁点击发送：

use Illuminate\Support\Facades\RateLimiter;
use Illuminate\Http\Request;

class SmsController extends Controller
{
    public function sendVerificationCode(Request $request)
    {
        $key = $request->ip() . '-' . $request->input('phone'); // 或者只用手机号
        $decayMinutes = 1; // 衰减时间，1分钟

        // 尝试执行，如果达到限制则返回false
        if (RateLimiter::tooManyAttempts($key, 3)) { // 允许3次尝试
            $retryAfter = RateLimiter::availableIn($key);
            return response()->json([
                'message' => '发送验证码过于频繁，请稍后重试。',
                'retry_after' => $retryAfter, // 告诉用户多久后可以重试
            ], 429);
        }

        // 如果没有达到限制，则记录一次尝试
        RateLimiter::hit($key, $decayMinutes * 60); // 记录一次尝试，并设置过期时间

        // 实际发送验证码的逻辑
        // ...

        return response()->json(['message' => '验证码已发送。']);
    }
}

这种方式让你能在业务逻辑内部精确控制速率，非常适合那些需要更细粒度限制的场景。

Laravel速率限制的底层原理是什么？它是如何工作的？

当我们谈论Laravel的速率限制，它背后其实是一套相对成熟且高效的机制，主要依赖于Laravel的缓存系统。在我看来，理解它的底层工作方式，能帮助我们更好地配置和排查问题。

核心组件是

Illuminate\Cache\RateLimiting\Limit

类和

Illuminate\Cache\RateLimiter

服务。

计数与存储： 当一个请求进入被速率限制的路由或代码块时，Laravel会生成一个唯一的“键”（Key）。这个键通常是基于请求的IP地址、认证用户的ID，或者你自定义的任何字符串。例如，
```
throttle:60,1
```
默认会使用请求的IP地址作为键。然后，它会尝试从配置的缓存驱动器（如Redis、Memcached或文件缓存）中获取这个键对应的计数器。如果计数器不存在，就初始化为1；如果存在，就加1。同时，它会记录这个计数器的“过期时间”，也就是当前限制窗口的结束时间。
缓存驱动器： Laravel的速率限制严重依赖于你的缓存配置。如果你使用Redis或Memcached，性能会非常好，因为它们是内存存储，读写速度快，而且支持原子操作，这对于并发请求下的计数器更新至关重要。如果使用文件缓存或数据库缓存，虽然也能工作，但在高并发场景下可能会有性能瓶颈，甚至出现竞态条件导致计数不准确（尽管Laravel会尽量规避）。我个人在生产环境中总是推荐使用Redis来处理速率限制。
判断与响应： 在每次请求时，
```
RateLimiter
```
会检查当前计数是否超过了你设定的最大允许次数。
- 未超限： 请求继续处理，计数器加1，并更新过期时间。
- 已超限： 请求会被拦截。
```
throttle
```
  中间件会抛出一个
```
TooManyRequestsHttpException
```
  异常，Laravel的异常处理器会将其转换为一个HTTP 429（Too Many Requests）响应。这个响应通常会包含一个
```
Retry-After
```
  HTTP头，告诉客户端多久之后可以再次尝试请求。这个
```
Retry-After
```
  值就是当前限制窗口剩余的秒数。
衰减与重置： 计数器并不会一直累加。当一个限制窗口结束时（例如，一分钟过去后），对应的缓存键就会过期，计数器会被自动重置。这就是“衰减”的概念。你配置的
```
perMinute(X)
```
或
```
perSecond(Y)
```
实际上就是定义了这个衰减窗口。

简单来说，它的工作流程就是：来一个请求 -> 检查缓存里有没有这个IP/用户的计数器 -> 有的话加1，没有就创建并设为1 -> 判断是否超过阈值 -> 没超就放行，超了就拒绝并告诉它多久再来。整个过程高效且可靠，很大程度上得益于底层的缓存系统。

如何为不同的用户类型或API端点设置定制化的速率限制策略？

在实际项目中，一刀切的速率限制策略往往不够用。比如，付费用户和免费用户、管理员和普通用户、图片上传接口和普通数据查询接口，它们对资源的需求和滥用的风险都不同。因此，定制化策略就显得尤为重要。

最灵活的方式，也是我最常用的方式，就是在

RouteServiceProvider

的

configureRateLimiting

方法中使用闭包（Closure）来定义。

1. 基于用户认证状态和角色：

你可以根据

$request->user()

是否存在来区分已认证和未认证用户，或者根据用户角色来设置不同的限制。

use Illuminate\Cache\RateLimiting\Limit;
use Illuminate\Http\Request;
use Illuminate\Support\Facades\RateLimiter;

protected function configureRateLimiting()
{
    // API限制：区分普通用户、VIP用户和未认证用户
    RateLimiter::for('api', function (Request $request) {
        if ($request->user()) {
            if ($request->user()->isVip()) { // 假设用户模型有isVip方法
                return Limit::perMinute(500)->by($request->user()->id); // VIP用户宽松
            }
            return Limit::perMinute(100)->by($request->user()->id); // 普通认证用户
        }
        return Limit::perMinute(60)->by($request->ip()); // 未认证用户按IP
    });

    // 针对管理员后台的API，通常限制可以更宽松，或者根本不限制（如果内部调用）
    RateLimiter::for('admin-api', function (Request $request) {
        if ($request->user() && $request->user()->isAdmin()) {
            return Limit::perMinute(1000)->by($request->user()->id);
        }
        // 非管理员尝试访问管理员API，可以给一个很低的限制甚至直接拒绝
        return Limit::perMinute(5)->by($request->ip());
    });
}

然后在路由中应用：

盛世企业网站管理系统1.1.2

免费盛世企业网站管理系统(SnSee)系统完全免费使用，无任何功能模块使用限制，在使用过程中如遇到相关问题可以去官方论坛参与讨论。开源系统Web代码完全开源，在您使用过程中可以根据自已实际情况加以调整或修改，完全可以满足您的需求。强大且灵活独创的多语言功能，可以直接在后台自由设定语言版本，其语言版本不限数量，可根据自已需要进行任意设置；系统各模块可在后台自由设置及开启；强大且适用的后台管理支

下载

Route::middleware(['auth:api', 'throttle:api'])->group(function () {
    // 普通API
});

Route::prefix('admin')->middleware(['auth:api', 'throttle:admin-api'])->group(function () {
    // 管理员API
});

2. 基于API端点或资源类型：

某些操作（如文件上传、创建新资源）可能比读取操作更耗费资源或更容易被滥用，所以它们需要更严格的限制。

protected function configureRateLimiting()
{
    // ... 其他限制器

    // 文件上传限制：防止用户短时间上传大量文件
    RateLimiter::for('file-upload', function (Request $request) {
        return Limit::perMinute(5)->by($request->user()->id ?: $request->ip());
    });

    // 搜索接口限制：搜索通常耗费数据库资源，可以单独限制
    RateLimiter::for('search', function (Request $request) {
        return Limit::perMinute(20)->by($request->user()->id ?: $request->ip());
    });
}

然后在路由中应用：

Route::post('/upload', [UploadController::class, 'store'])
    ->middleware('throttle:file-upload');

Route::get('/search', [SearchController::class, 'index'])
    ->middleware('throttle:search');

3. 基于API Key：

如果你对外提供API服务，通常会给开发者分发API Key。你可以通过API Key来识别并限制请求。这需要你有一个API Key的验证中间件，并在其中将API Key信息注入到请求对象中。

// 假设你有一个中间件 ValidateApiKey，它会把api_key_id放入$request中
RateLimiter::for('api-key-access', function (Request $request) {
    if ($request->has('api_key_id')) { // 假设API Key ID存在
        // 根据API Key ID查询其对应的限制策略，例如：
        // $apiKey = ApiKey::find($request->input('api_key_id'));
        // return Limit::perMinute($apiKey->limit)->by($apiKey->id);
        return Limit::perMinute(200)->by($request->input('api_key_id')); // 示例
    }
    return Limit::perMinute(10)->by($request->ip()); // 没有API Key的按IP限制
});

路由应用：

Route::middleware(['validate.api.key', 'throttle:api-key-access'])->group(function () {
    // 对外开放的API
});

通过这些定制化的策略，我们可以根据业务场景的实际需求，灵活地为不同的用户和功能设置合适的速率限制，从而在保护系统资源的同时，也能提供良好的用户体验。这种细粒度的控制能力，是我认为Laravel速率限制机制最强大之处。

速率限制对用户体验和系统性能有哪些影响？如何平衡？

速率限制是一把双刃剑，用得好能保护系统，用得不好则可能损害用户体验。在我看来，理解它对两者的影响，并找到一个恰当的平衡点，是实现一个健壮应用的关键。

对用户体验的影响：

负面反馈： 最直接的影响就是用户会收到
```
429 Too Many Requests
```
错误。如果用户不理解为什么会收到这个错误，或者没有明确的提示，他们可能会感到困惑、沮丧，甚至认为应用出了问题。
中断工作流： 想象一下，用户正在进行一系列操作，突然因为速率限制而被打断，这无疑会影响他们的流畅体验。
误伤正常用户： 如果限制设置得过于严格，可能会“误伤”那些只是正常使用，但请求频率稍高的用户。比如，一个网络条件不佳的用户，可能因为多次重试而意外触及限制。
透明度问题： 如果API文档没有明确说明速率限制策略，开发者在使用你的API时会遇到不必要的麻烦，降低集成效率。

对系统性能的影响：

保护核心资源： 这是速率限制最主要的目的。它可以有效阻止恶意爬虫、DDoS攻击或简单的大量无效请求，从而保护你的数据库、CPU、内存等核心服务器资源不被耗尽。
降低服务成本： 减少了不必要的请求处理，意味着更低的服务器负载，从而可能降低你的云服务账单。
提高服务稳定性： 在高并发场景下，速率限制可以作为一道防线，防止系统过载崩溃，确保核心服务能够持续运行。
缓存开销： 虽然速率限制保护了应用，但它自身也需要消耗一定的资源来存储和管理计数器（通常在缓存中）。如果你的缓存系统（如Redis）处理能力不足，或者限制器数量庞大，这部分开销也可能成为新的性能瓶颈。

如何平衡用户体验与系统性能：

要在这两者之间找到最佳平衡点，需要策略性和持续的优化：

合理设置阈值：
- 基于业务需求： 区分不同接口的重要性、消耗资源程度以及被滥用的风险。例如，登录、注册、发送验证码等关键操作的限制应更严格；而普通的数据查询可以相对宽松。
- 监控与调整： 不要一次性设置死板的限制。上线后，通过监控工具（如Prometheus, Grafana, Sentry）观察用户的请求模式和系统负载。如果发现大量正常用户触及限制，说明可能太严格了；如果系统经常过载，可能需要收紧。
- 区分用户： 就像前面提到的，为认证用户、未认证用户、VIP用户、管理员等设置不同的限制。
友好的错误提示：
- 明确的错误信息： 当用户收到
```
429
```
  响应时，错误信息应该清晰地告诉他们为什么会受限，以及多久后可以重试。例如：“请求过于频繁，请在X秒后重试。”
- Retry-After
  头：确保你的
```
429
```
  响应中包含
```
Retry-After
```
  HTTP头，这对于客户端（尤其是API消费者）进行自动化重试非常有用。
客户端策略：
- 指数退避（Exponential Backoff）： 对于API消费者，建议在收到
```
429
```
  响应后，不要立即重试，而是等待一段时间，并且每次重试失败后，等待时间成倍增加。这能有效减轻服务器压力，并提高请求成功的几率。
- 客户端缓存： 鼓励客户端缓存不经常变动的数据，减少不必要的请求。
提供缓冲或弹性：
- Bursting (突发)： 某些速率限制算法允许在短时间内超过平均速率，以应对突发流量，但长期平均速率仍受控。Laravel的
```
Limit::perMinute(60)->by($request->ip())
```
  在一定程度上就有这种弹性。
- 队列处理： 对于非实时性要求高的操作（如批量数据导入），可以将其放入消息队列中异步处理，而不是直接响应，从而避免触及速率限制。
透明的文档：
- API文档： 在你的API文档中清晰地说明每个端点的速率限制策略、错误响应格式以及推荐的重试机制，让开发者心里有数。