Laravel速率限制通过throttle中间件和RateLimiter门面实现，基于缓存系统为不同用户、IP或API端点设置请求阈值，防止滥用并保护服务器资源。
Laravel的速率限制（Rate Limiting）功能，说白了，就是给你的应用设一道“门禁”，控制在一定时间段内，某个用户、某个IP或者某个API密钥能向你的服务器发送多少次请求。这玩意儿可太重要了，它能有效防止恶意刷接口、DDoS攻击，或者仅仅是避免你的API被过度调用，导致服务器资源耗尽。设置起来其实不复杂，主要通过路由中间件或者更灵活的
RateLimiter
Facade来搞定。
解决方案
要设置Laravel的请求限制，我们通常有两种主要途径，各有侧重：
1. 使用路由中间件 (Route Middleware) 进行全局或分组限制
这是最常见也最直接的方式。Laravel提供了一个开箱即用的
throttle
中间件。
首先，你可以在
app/Providers/RouteServiceProvider.php
文件的
configureRateLimiting
方法中定义你的速率限制器。这是我个人比较推荐的做法，因为它把所有的限制策略集中管理起来，清晰明了。
use IlluminateCacheRateLimitingLimit;use IlluminateSupportFacadesRateLimiter;/** * 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 IlluminateSupportFacadesRateLimiter;use IlluminateHttpRequest;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的缓存系统。在我看来，理解它的底层工作方式，能帮助我们更好地配置和排查问题。
核心组件是
IlluminateCacheRateLimitingLimit
类和
IlluminateCacheRateLimiter
服务。
计数与存储：当一个请求进入被速率限制的路由或代码块时，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)
实际上就是定义了这个衰减窗口。
简单来说，它的工作流程就是：来一个请求 -youjiankuohaophpcn 检查缓存里有没有这个IP/用户的计数器 -> 有的话加1，没有就创建并设为1 -> 判断是否超过阈值 -> 没超就放行，超了就拒绝并告诉它多久再来。整个过程高效且可靠，很大程度上得益于底层的缓存系统。
如何为不同的用户类型或API端点设置定制化的速率限制策略？
在实际项目中，一刀切的速率限制策略往往不够用。比如，付费用户和免费用户、管理员和普通用户、图片上传接口和普通数据查询接口，它们对资源的需求和滥用的风险都不同。因此，定制化策略就显得尤为重要。
最灵活的方式，也是我最常用的方式，就是在
RouteServiceProvider
的
configureRateLimiting
方法中使用闭包（Closure）来定义。
1. 基于用户认证状态和角色：
你可以根据
$request->user()
是否存在来区分已认证和未认证用户，或者根据用户角色来设置不同的限制。
use IlluminateCacheRateLimitingLimit;use IlluminateHttpRequest;use IlluminateSupportFacadesRateLimiter;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()); });}
然后在路由中应用：
卡拉OK视频制作
卡拉OK视频制作，在几分钟内制作出你的卡拉OK视频
178 查看详情 
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文档中清晰地说明每个端点的速率限制策略、错误响应格式以及推荐的重试机制，让开发者心里有数。
总而言之，速率限制并非一劳永逸的配置，它需要持续的关注、监控和迭代。只有在充分理解业务需求、用户行为和系统性能的前提下，才能找到那个既能有效保护系统，又能尽可能不影响用户体验的甜蜜点。
以上就是Laravel速率限制？请求限制如何设置？的详细内容，更多请关注php中文网其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/272789.html
微信扫一扫 
支付宝扫一扫 
