前端无法真正实现服务端级令牌桶限流，但可构建以“感知+反馈”为核心的客户端节流层，通过performance.now()模拟填充、X-RateLimit-Remaining和Retry-After实现自适应协同限流。
前端无法真正实现服务端级的令牌桶限流，但可以构建一个轻量、自适应、以“感知+反馈”为核心的客户端节流层——它的价值不在于拦住所有超额请求，而在于让 UI 及时响应后端的真实状态，避免用户反复点击触发 429。
为什么 NewLimiter 在浏览器里根本跑不通
Go 的 rate.NewLimiter 依赖系统时钟精度、原子共享状态和阻塞等待能力，这三者在浏览器中全都不成立：
-
Date.now()可被用户手动篡改，performance.now()虽更准但仍是相对时间，跨 Tab / 刷新即失效 - 没有跨进程/跨标签页的全局计数器，每个页面实例都维护自己的“桶”，恶意用户清空
localStorage就绕过 - JS 没有
Wait或线程阻塞机制，所谓“等 token 到位”只能靠setTimeout，但用户切走再切回会导致时间差误判 - 桶容量
b和速率r若和服务端不一致（比如后端是 100 req/min，前端误设为 10 req/s），会直接放大限流失效风险
如何用 performance.now() 模拟令牌填充逻辑
核心是把“桶”当作一个本地缓存状态机，只用于预判 + 快速拒绝，不用于最终决策：
PigX UI 前端开发
下载
PigX UI Pro 前端开发指南 - Vue 3 + TypeScript + Element Plus。当用户提到 PigX UI、PigX 前端、lgb-mgui 项目、Vue 3 企业级后台开发、Element Plus 后台开发时使用此技能。
- 初始化时设
capacity = 100、rate = 100 / 60（即每秒约 1.67 个），与后端规则对齐 - 每次请求前调用
refill()：用performance.now() - lastRefillTime计算毫秒差，乘以rate得新增令牌数，再取min(capacity, currentTokens + newTokens) - 若
currentTokens >= 1，则扣减 1 并更新lastRefillTime；否则立即拒绝，不发请求 - ⚠️ 关键细节：必须用
performance.now()，不能用Date.now()，否则用户调快系统时间会导致桶“无限充能”
怎么利用 X-RateLimit-Remaining 和 Retry-After 实现真自适应
前端自己算的永远只是估算，后端响应头才是唯一可信来源。重点不是“我猜还剩几个 token”，而是“后端说还剩几个、什么时候重置”：
立即学习“前端免费学习笔记（深入）”；
- 收到成功响应时，立刻用
X-RateLimit-Remaining覆盖本地currentTokens，并用X-RateLimit-Reset更新本地倒计时基准 - 收到
429 Too Many Requests且含Retry-After: 60，立即暂停该接口所有请求至少 60 秒，并同步更新 UI（如按钮变灰、显示“60s 后重试”） - 即使本地桶还有 token，只要
X-RateLimit-Remaining === 0，就应主动降级行为（如禁用提交按钮、展示限流提示） - ⚠️ 容易忽略的点：不同 API 路径可能对应不同限流策略，
X-RateLimit-*头必须按路径或用户 ID 隔离缓存，不能全局共用一个桶状态
真正难的不是写几行 refill 逻辑，而是把“前端节流”从防御性设计转为协同式设计——它不替代后端限流，而是成为后端限流的延伸感官。一旦你开始依赖 Retry-After 控制重试节奏、用 X-RateLimit-Reset 驱动 UI 倒计时，你就已经踩在了自适应的正确路线上。
