应为登录回调、Webhook接收、内部服务探活等关键路径加白名单，通过路由层显式剔除throttle中间件或自定义RateLimiter策略实现免限流，避免429中断核心链路。
哪些路由该加白名单：用 throttle 中间件前先看实际场景
Laravel 默认的 throttle 中间件对所有打到该路由组的请求一视同仁，但登录回调、Webhook 接收、内部服务探活这些路径根本不能被限流。不加白名单，429 Too Many Requests 会直接打断关键链路。
- 白名单不是“信任所有”，而是“绕过速率检查”——它不跳过认证或授权，只跳过计数逻辑
- 最稳妥的位置是路由定义层，而不是在中间件里写 if 判断，避免漏掉中间件顺序问题
- 如果用的是 Laravel 9+ 的闭包路由或控制器方法级注册，白名单必须显式绑定，不能依赖全局中间件配置
怎么给单个路由免限流：直接在 Route::middleware() 里剔除 throttle
Laravel 没有内置“白名单开关”，所谓“免限流”，本质是让某些路由不应用 throttle 中间件。别试图在 app/Http/Kernel.php 里注释掉 throttle，那会全局失效。
- 在定义路由时，用
->withoutMiddleware(ThrottleRequests::class)（Laravel 8+） - 或更明确地重写中间件栈：
->middleware(['auth:sanctum', 'bindings'])，不带throttle - 若路由属于某个命名组（如
api），又只想放行其中几个，就别用Route::middleware('api')统一挂载，拆出来单独配
Route::post('/webhook/stripe', [WebhookController::class, 'handleStripe'])
->withoutMiddleware(\Illuminate\Routing\Middleware\ThrottleRequests::class);想动态控制白名单？别碰中间件类本身，改用自定义 throttle 策略
硬编码白名单 IP 或 UA 不可持续，也容易被绕过。真正需要动态判断时（比如只对内网调用免限流），应该复写 throttle 的解析逻辑，而不是在中间件里加一堆 if。
Laravel Cloud
下载
Laravel Cloud（cloud.laravel.com）。此技能用于处理所有 Laravel Cloud 请求，包括搜索和读取数据。只要任务涉及 Laravel Cloud，即使用此技能。
- 在
app/Providers/RouteServiceProvider.php的configureRateLimiting方法里，用RateLimiter::for()定义新策略 - 利用
$request->ip()或$request->header('X-Internal-Call')做条件分支，返回Limit::none()表示不限流 - 注意：策略名要和路由中间件参数一致，比如
->middleware('throttle:api,1')对应的策略名是'api'
RateLimiter::for('api', function (Request $request) {
if ($request->ip() === '10.0.0.1' || $request->header('X-Internal-Call')) {
return Limit::none();
}
return Limit::perMinute(60)->by($request->user()?->id ?: $request->ip());
});测试白名单是否生效：别只看响应码，盯住 Redis key 和日志
429 消失了不等于限流真的绕过了。Laravel 的 throttle 底层依赖 Redis 计数器，如果白名单逻辑写错，可能只是没命中 key，而计数器还在默默累加。
- 手动查 Redis：
redis-cli keys "<em>rate_limit:</em>"，对比白名单路由和普通路由的 key 是否都存在 - 开启 Laravel 日志中的
debug级别，搜索throttled或RateLimiter，确认策略是否被调用 - 最容易踩的坑：在
withoutMiddleware()后又不小心在控制器里调用了RateLimiter::attempt()，这种手动限流不会被自动跳过
白名单不是加个标记就完事，它牵扯中间件执行顺序、策略匹配逻辑、底层存储行为——哪怕只漏掉一个 ->middleware() 调用点，限流就会悄无声息地咬住你。
