必须重写限流签名逻辑，创建继承throttlerequests的apithrottlerequests中间件，重写resolverequestsignature方法以bearer token哈希或ip区分用户与游客，并在kernel中注册、路由中绑定，同时确保redis配置正确且路由处于api组内。
要在Laravel中对API接口按用户身份、设备指纹或业务维度做差异化限流，必须重写限流签名逻辑——否则无法区分登录用户与游客、JWT Token与Session登录、同一IP下的多个合法终端。
创建自定义限流中间件
执行 Artisan 命令生成中间件类：php artisan make:middleware ApiThrottleRequests。
该命令会自动在 app/Http/Middleware 下创建文件，并确保命名空间、handle() 方法签名和 Closure $next 参数类型完全符合 Laravel 自动加载规范；【手动创建的类即使内容一致也不会被加载】。
打开新生成的 ApiThrottleRequests.php 文件，继承 \Illuminate\Routing\Middleware\ThrottleRequests 而非从头写。
重写 resolveRequestSignature 方法
在 ApiThrottleRequests 类中覆盖父类方法：
protected function resolveRequestSignature($request) {
return $request->bearerToken() ? 'user_token_' . hash('sha256', $request->bearerToken()) : 'guest_ip_' . $request->ip();
}
这一步决定每个请求被分配到哪个“计数桶”：Bearer Token 用户走 token 哈希桶，游客走 IP 桶。不能直接返回 $request->bearerToken()——它可能被伪造，哈希后可防枚举；也不要用 $request->session()->id()，无状态 API 下 session 可能未启动。
注意：若使用 Passport 或 Sanctum，需确认 $request->bearerToken() 已经过中间件验证（如 auth:sanctum），否则未解码的 token 会导致限流失效。
配置路由并绑定中间件
第一步：在 app/Http/Kernel.php 的 $routeMiddleware 数组中注册别名：
'api.throttle' => \App\Http\Middleware\ApiThrottleRequests::class,
第二步：在路由定义中应用，例如：
Route::get('/v1/profile', [ProfileController::class, 'show'])->middleware('api.throttle');
第三步：确保该路由已处于 api 中间件组内，否则 $request->bearerToken() 不可用——因为 auth:sanctum 等认证中间件不会在 web 组中自动运行。
这一步漏掉会导致 $request->bearerToken() 始终为空，所有请求都落入 guest_ip_* 桶，NAT 环境下极易误杀。
验证限流行为是否生效
① 启动 Redis 服务并确认 CACHE_DRIVER=redis、REDIS_CLIENT=predis 已在生产环境 .env 中正确设置；【file 或 array 驱动下多进程各自计数，限流完全失效】。
② 使用 curl 发送带 Bearer Token 的请求：curl -H "Authorization: Bearer abc123" http://localhost:8000/v1/profile，连续触发 61 次后应返回 HTTP 429。
③ 换一个 IP（或用代理）不带 Token 访问同一接口，观察是否独立计数——此时应从第 1 次开始重新累计，而非延续前一用户的计数。
④ 查看 Redis 中键名：rate_limit:user_token_* 和 rate_limit:guest_ip_* 是否真实存在且 TTL 正常，可用 redis-cli keys "rate_limit:*" 快速确认。
