vue 3请求拦截器可结合令牌桶等算法实现客户端限流，通过时间戳缓存判断请求频次，支持动态策略、排队等待及abortcontroller取消，但不能替代服务端限流。
Vue 3 中请求拦截器本身不直接提供限流能力，但可以结合令牌桶（Token Bucket）或滑动窗口等算法，在请求拦截器中实现轻量、可控的客户端请求频率限制。关键不是“拦截所有超频请求”，而是“在发出前判断是否允许本次请求”，避免无效请求堆积或触发服务端熔断。
用拦截器 + 时间戳缓存做简易令牌桶
适合中低频场景（如每秒最多 3 次、每分钟最多 20 次），无需额外依赖，逻辑清晰易维护：
- 定义一个全局缓存对象，记录每个接口 URL（或 key）最近几次请求的时间戳数组
- 在请求拦截器中，根据配置的限流规则（如 limit=5, windowMs=60000）计算当前窗口内已发请求数
- 若超出阈值，可选择：直接 reject 报错、返回 Promise.delay 后重试、或静默丢弃并 warn 提示
示例代码（精简版）：
const rateLimitCache = new Map<string number>();
<p>service.interceptors.request.use(config => {
const key = config.url || 'default';
const limit = config.headers?.['X-Rate-Limit'] || 5;
const windowMs = 60 * 1000;</p>
<p>const now = Date.now();
const timestamps = rateLimitCache.get(key) || [];</p>
<p>// 清理过期时间戳
const validTimestamps = timestamps.filter(ts => now - ts </p>
<p>if (validTimestamps.length >= limit) {
return Promise.reject(new Error(<code>Request rate exceeded for ${key}</code>));
}</p>
<p>rateLimitCache.set(key, [...validTimestamps, now]);
return config;
});</p></string>配合 AbortController 实现“排队等待”式限流
比直接拒绝更友好，适用于用户主动触发类操作（如搜索、刷新按钮），让超额请求自动延后执行：
- 为同一类请求（如
/api/search）维护一个队列 - 拦截器中不立即发请求，而是将 config 和 resolve/reject 封装进任务，推入队列
- 用定时器或递归方式按固定间隔（如 200ms）从队列取任务执行，同时控制并发数
- 每个任务自带 AbortSignal，超时或被新请求覆盖时可主动取消
与 Pinia 状态联动，支持动态限流策略
当限流规则需随用户角色、网络状态或业务阶段变化时，可在拦截器中读取 Pinia store：
- 例如：游客用户限流更严（/user/profile → 1次/30s），VIP 用户放宽（→ 5次/30s）
- store 中定义
rateLimits: Record<string limit: number window:></string> - 拦截器中通过
useUserStore().rateLimits[config.url]动态获取策略 - 策略变更时，自动清空对应 key 的缓存，避免 stale 数据
注意事项与边界提醒
客户端限流本质是“尽力而为”的体验优化，不能替代服务端限流：
- 不可绕过：用户可禁用 JS、篡改 localStorage 或直接调用 API，因此服务端必须有独立限流（如 Redis + 滑动窗口）
- 多标签页不同步：各页面实例缓存隔离，需用 BroadcastChannel 或 IndexedDB 做跨 tab 协同（复杂度高，一般不推荐）
- 避免阻塞主流程：限流判断必须同步、无 await；异步逻辑（如查 IndexedDB）应降级为默认宽松策略
- 区分请求类型：GET 查询可适当宽松，POST/PUT/DELETE 等写操作建议更严格，甚至禁止重复快速提交
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
