API 速率限制头解析器 - 解读 X-RateLimit 信息

API 速率限制是服务端对客户端在特定时间窗口内可发送请求数量的上限。这是一种保护机制，防止单个客户端过度消耗服务器资源，确保所有用户都能公平访问 API。当超过限制时，API 通常会返回 HTTP 429 Too Many Requests 状态码，并在响应头中包含 X-RateLimit-* 或 Retry-After 等信息告知客户端当前状态。不同平台的限制策略各不相同，有的按分钟计算，有的按小时或天计算，有的则采用滑动窗口或令牌桶等更复杂的算法。

最常见的速率限制头包括：X-RateLimit-Limit 表示时间窗口内的总请求配额；X-RateLimit-Remaining 表示当前窗口内剩余的请求次数；X-RateLimit-Reset 表示配额重置的 Unix 时间戳（秒）；X-RateLimit-Used 表示已使用的请求次数；Retry-After 表示达到限制后建议等待的秒数（或 HTTP 日期）；X-RateLimit-Resource 标识限制适用于的资源类型。不同平台可能使用略有差异的命名，例如 OpenAI 使用 x-ratelimit-remaining-requests 等格式，Twitter 使用小写的 x-rate-limit-* 前缀。

使用率计算公式为：(Limit - Remaining) / Limit * 100% 或直接使用 Used / Limit * 100%。例如 GitHub 返回 Limit=5000，Remaining=3250，则已使用 1750，使用率为 35%。一般建议当使用率超过 75% 时开始采取节流措施，超过 90% 时紧急降低请求频率以避免触发 429 错误。本工具的仪表盘会自动计算并以颜色直观显示当前使用率状态，绿色表示安全（低于 60%），黄色表示警告（60%-85%），红色表示危险（高于 85%）。

收到 429 响应时：首先检查 Retry-After 头，它会明确告知需要等待的秒数；其次实现指数退避策略，首次等待 1 秒，随后 2 秒、4 秒、8 秒逐步增加；同时添加抖动（Jitter），在退避时间中加入随机延迟，避免多个客户端同时重试造成惊群效应；还要检查 X-RateLimit-Reset 头了解窗口何时完全重置，规划后续请求节奏；最后考虑缓存响应，对不频繁变化的数据使用本地缓存，减少不必要的 API 调用。本工具的 429 重试预设可以帮助您了解这种场景下的响应头格式。

主要区别在于限制算法和粒度：固定窗口在固定时间段内限制请求数，窗口结束时重置，简单但可能在窗口边界出现突发流量；滑动窗口动态计算最近一段时间内的请求数，更平滑但实现复杂；令牌桶以恒定速率填充令牌，每次请求消耗令牌，允许短时突发（如 Stripe）；漏桶请求进入队列以固定速率处理，严格平滑流量；分层限制如 OpenAI 同时限制 RPM（每分钟请求数）和 TPM（每分钟 Token 数），需要同时关注多个维度的使用率。本工具的参考表汇总了主流平台的策略差异。

优化策略包括：使用条件请求，利用 ETag/If-None-Match 和 Last-Modified/If-Modified-Since 头，当数据未变更时返回 304 不消耗配额；批量操作，优先使用支持批量处理的端点，一次请求完成多个操作；合理缓存，在客户端或中间层缓存响应，设置合适的 TTL；请求合并，将多个独立请求合并为一个复合请求；监控使用率，持续跟踪 X-RateLimit-Remaining，在接近阈值时主动降速；升级认证，使用 API Key 或 OAuth 通常能获得更高配额，例如 GitHub 未认证用户仅 60 次/小时，认证用户 5000 次/小时。

绝对安全。本工具所有解析逻辑都在浏览器本地执行，不涉及任何服务器通信。您粘贴的 HTTP 响应头数据不会被发送到任何外部服务器，完全在您的浏览器内存中处理。这意味着即使响应头中包含敏感信息（如 API Key 相关的头部），也不存在数据泄露风险。关闭页面后所有数据自动清除。本工具不使用任何第三方分析或跟踪脚本。

不同 API 平台对速率限制头的支持程度不同。有些平台只返回 Limit 和 Remaining，不返回 Reset 或 Used；有些平台使用自定义头名称而非标准的 X-RateLimit-* 前缀；还有些平台只在触发 429 时才在响应头中包含限制信息。对于字段不完整的情况，本工具会尽可能解析已有的字段，并圪详情表中标注缺失的字段。您也可以使用手动编辑模式补充缺失的值，以便进行完整的分析。工具的预设场景涵盖了常见的字段组合情况。