token限流不能只靠内置throttle中间件，因其默认按ip或会话限流，无法精准识别用户级token；必须手动解析authorization头中的token，提取jti/sub或sha256哈希生成限流key，并用redis lua脚本实现原子计数与过期控制。
Token限流为什么不能只靠内置的 throttle 中间件
ThinkPHP 自带的 throttle 中间件默认基于 IP 或会话 ID 限流，无法按用户级 Token（如 JWT、OAuth2 access_token）做精准控制。一旦接口面向 App 或第三方调用，Token 才是真实身份标识，IP 可能被代理层统一、会话可能未启用，直接套用会导致误限或失效。
常见错误现象包括：429 Too Many Requests 频繁触发但实际请求者不同，或同一 Token 在多设备登录时被错误合并计数。
- 必须从请求头（如
Authorization: Bearer xxx）提取 Token 字符串作为限流 key - 不能复用
throttle的cache驱动配置——它默认用 IP 做 key 前缀，需绕过或重写 - Token 解析失败时应降级为 IP 限流，而非直接报错中断请求
如何手动解析 Token 并生成唯一限流 key
不要依赖第三方 JWT 库做完整验签后再限流——验签耗时高，且限流只需识别身份，不需业务级合法性。建议在中间件中做轻量解析：提取 Token 头部 + payload 的 jti（JWT ID）或 sub（subject），若不存在则 fallback 到 sha256(Token)。
示例逻辑（放在中间件 handle() 中）：
// 从 Authorization 头提取 token
$auth = $request->header('authorization', '');
$token = preg_match('/^Bearer\s+(.+)$/', $auth, $matches) ? $matches[1] : null;
$key = 'rate_limit:';
if ($token) {
// 尝试 JSON 解码 header.payload（无需 base64_decode 全量，只取前两段）
$parts = explode('.', $token);
if (count($parts) >= 2) {
try {
$payload = json_decode(base64_decode(str_replace(['-', '_'], ['+', '/'], $parts[1])), true);
$key .= $payload['jti'] ?? $payload['sub'] ?? hash('sha256', $token);
} catch (\Exception $e) {
$key .= hash('sha256', $token);
}
} else {
$key .= hash('sha256', $token);
}
} else {
$key .= $request->ip();
}
注意：hash('sha256', $token) 比直接用原始 Token 更安全，避免缓存 key 泄露敏感信息；jti 是最理想的字段，因它本就设计为唯一标识一次 Token 发行。
使用 Cache 驱动实现原子计数与过期控制
ThinkPHP 的 Cache::inc() 不是原子操作（尤其在 Redis Cluster 下），直接调用会导致计数偏差。必须用 Lua 脚本或原生命令封装——推荐直接调用底层 Redis 实例的 eval()。
- 限流窗口用 Redis 的
EXPIRE配合INCR，脚本需保证「计数 + 设置过期」一次性完成 - 避免用
Cache::remember()，它读写分离，无法满足原子性 - 测试时务必开启
redis缓存驱动，file驱动不支持原子递增
实操建议：在中间件中这样写（假设已配置 redis 为默认缓存）：
$redis = \think\facade\Cache::store('redis')->getRedis();
$window = 60; // 秒
$maxAttempts = 10;
// Lua 脚本确保原子性
$script = 'local current = redis.call("INCR", KEYS[1]) if current == 1 then redis.call("EXPIRE", KEYS[1], ARGV[1]) end return current';
$current = $redis->eval($script, [$key], 1, $window);
if ($current > $maxAttempts) {
throw new \think\exception\HttpException(429, 'Too Many Requests');
}
中间件注册与路由分组适配要点
限流中间件必须放在认证中间件之后，否则拿不到有效 Token；但要在业务逻辑之前。如果用 AuthMiddleware 解析并写入 $request->user，你的限流中间件应声明依赖它：
// app/middleware/RateLimitMiddleware.php
public function handle($request, \Closure $next)
{
// 确保 AuthMiddleware 已执行
if (!$request->has('user')) {
// 可选：记录 warn 日志，或 fallback 到 IP 限流
$key = 'rate_limit:ip:' . $request->ip();
// ... 后续计数逻辑
}
// ...
return $next($request);
}
注册时注意作用域：
- 全局注册（
app/middleware.php）→ 影响所有请求，慎用 - 路由分组注册 → 推荐，例如 API 组合用
group(['middleware' => 'rate_limit']) - 单个路由注册 → 适合高频核心接口，如
Route::post('pay', 'PayController@submit')->middleware('rate_limit')
别忽略并发场景下的缓存穿透：当大量非法 Token 请求涌入，每个都生成新 key，Redis 内存可能被撑爆。应在解析 Token 失败时加白名单或固定 key 限流，而不是放任散列。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
