你要给团队写一份接口文档，或者对接一个海外服务，后台里冒出来一堆 quota、rate limit、credit、throttle 之类的词，看着都认识，真要落到「哪个是总量、哪个是频率、哪个是余额」就开始含糊。这篇按「额度类」「限制类」「超限与恢复类」三组把常用英文说法和它们对应的中文场景对上，再给一张查词和拼写自查的动作清单，让你写文档时不用猜词。
给团队写接口文档，或者对接一个海外服务，后台里冒出来 quota、rate limit、credit、throttle 一串词，看着都眼熟，真要落到「哪个是总量、哪个是频率、哪个是余额」就开始含糊。这种含糊不是英语问题，是概念没归位。下面按额度类、限制类、超限与恢复类三组把常用说法和它们对应的中文场景对上。
先说明范围：这篇只解决「认词和用词」，不涉及具体某家平台给你的数字。各家口径和当期规则会变，写到文档里的数值一律去站内额度与计费相关页面核对当时的数字，别从旧文档里抄。判断类内容也有不适用的情况，比如面向纯内部同事的文档，中英混写反而更容易出错，那就直接全中文、只在字段名保留英文原词。
先分清 quota、limit、credit、balance 这四个词
这四个词是文档里最容易混的一组。判断标准很简单：看它修饰的是什么对象。修饰一个周期内可消耗的总量，用 quota；修饰一个不可越过的界线，用 limit。两者经常同时出现，但落点不同——quota 是「你有多少」，limit 是「最多到哪」。写文档时如果一句话里两个词都出现，建议明确写清谁限制谁。
- quota
- 配额、周期内可用总量，通常带时间口径（按天/按月）
- limit
- 上限、约束界线，可以是数字上限，也可以是行为约束
- credit
- 平台给的可用金额或点数，常来自赠送或预充
- balance
- 账户余额，和 credit 混用会让读者误判扣费顺序
- allowance
- 平台划给你的可用份额，语气上更偏「允许你用这么多」
- usage-based
- 按量计费，强调用多少算多少，而非固定档位
- usage 是已用量，remaining / left 是剩余量，文档里别把这两个当同义词替换
- 看到 quota exhausted 和 quota exceeded，前者偏状态、后者偏动作结果，报错文案里两种都常见
- 给非英语同事写内部文档，英文词后面加一句中文口径，比如 quota（本周期可用总量）
- 同一份文档里不要一会儿把 quota 译成「额度」一会儿译成「配额」，统一一个说法
限制类高频词：频率、并发、并发连接怎么区分
限制类的词比额度类更容易让人误会，因为它们不涉及「用完」，只涉及「太快」。判断标准是看单位：带时间单位的（每分钟、每秒）多半是频率限制；不带时间、只描述同时存在多少的，多半是并发限制。被 throttle 通常不是额度没了，而是短时间请求太密触发了保护。
| 英文说法 | 管的是什么 | 什么时候不适用 |
|---|---|---|
| rate limit | 单位时间内的请求次数 | 想表达「同时能跑几条」时不适用 |
| RPM / TPM | 每分钟请求数 / 每分钟 token 数 | 计量单位换成金额或字符数时不适用 |
| concurrency | 同一时刻允许并行的请求数 | 描述平均吞吐量时不适用 |
| throttle | 被限流的状态，偏动词 | 额度彻底用尽时用它不准确 |
| burst | 允许的瞬时突发量 | 没有宽限窗口的平台不存在这个词 |
写文档时的落地做法：在字段表里把「频率限制」和「并发限制」分成两行，别合并成一行「限制」。合并之后对接方一定会来问，反而多一轮沟通。另外 burst 这类词如果平台没明确给，就不要在文档里替它假设存在。
超限、重置与恢复：把报错文案和状态词对上
这一组词的共同点是，翻译成中文都像「恢复」「超了」，但触发条件差别很大。判断标准看触发源：由时间周期驱动的用 reset；由手动操作或续期驱动的用 renew；由你在周期内多用了驱动的用 overage。写文档时把触发条件写出来，比只给中文翻译有用得多。
- exceeded / exhausted 表示已用尽，前者更像「越过了线」，后者更像「存量见底」
- insufficient quota 指额度不够，多出现在请求被拒的返回里
- overage 指超出部分，很多平台对超出部分是另算而不是直接停服
- reset 周期到点自动恢复，refresh 是刷新状态，renew 偏手动续期
- cooldown 是触发限制后的冷却期，retry-after 是响应头里告诉你隔多久再试的字段
- 先看报错里的动词是 exceeded、exhausted 还是被 throttle，先判断是额度用尽还是频率过密，方向不对后面全错
- 再看有没有时间字段带 reset 时间的多半是周期额度，带 retry-after 的多半是频率限制
- 去站内核对当期口径拿不准某个词对应哪套规则时，到站内额度与计费相关页面核对当时的数字和周期说明，别照旧文档抄
- 在响应处理里留分支区分「等一会儿再试」和「等周期重置」，前者可以重试，后者重试只会继续失败
还有一种情况要单独说：如果对接的服务同时有网页版和 API，两边的额度字段名经常不一样，别默认它们共用同一个 quota 口径。判断标准是看字段底下挂的周期和计量单位是否一致，不一致就当成两套规则分别写。
落地清单：写文档和看后台时按这四步走
前面把词分了组，这一步给能直接照做的顺序。整套动作大概十分钟，能省掉后面反复来回确认的时间。前提是你手上已经有一份要写的字段表或一份要读的后台报错，没有具体材料时这套清单用不上。
- 认词归位先判断看到的词属于总量额度、频率限制、账户余额、已用量哪一类，再决定要不要翻译成中文
- 找口径页拿不准某个词对应哪套规则时，先去站内额度与计费相关页面核对当期口径，别照着旧文档抄
- 统一写法同一份文档里 quota 只表示总量、limit 只表示上限，避免读者反复回来确认
- 留一栏备注在字段表里加一列「中文口径」，写清周期（按天/按月）、计量单位（次数/token/金额）和超限后的行为
| 自查项 | 合格标准 | 不合格的典型表现 |
|---|---|---|
| 同一词多译 | 全文一个英文词只对应一个中文说法 | quota 一会儿「额度」一会儿「配额」 |
| 周期缺失 | 每个额度字段都标了周期 | 只写「额度」不写按天还是按月 |
| 限制混行 | 频率限制和并发限制分两行 | 两种限制塞进一行「限制」 |
| 恢复方式 | 写清是自动重置还是手动续期 | 统一写「恢复时间」 |
这套清单有个不适用的情况：如果文档读者全是英语母语者，中文口径那一列反而是干扰，可以改成只保留英文原词加一句英文解释。另外字段表如果只是内部临时用，不用强行补周期，够自己看懂就行。
下一步各家平台对同一批词的用法并不完全一致，写文档前到站内 API 价格与模型资料库核对当期口径，比翻旧文档稳。→常见问题
quota 和 limit 到底该怎么选，能互换吗？
日常口语里经常混着用，但正式文档建议分开：quota 用来指「你这段时间能用多少」，limit 用来指「最多不能超过多少」。两者可能同时存在，比如一个账号有总量配额，同时对每分钟请求数也有上限，混用会让读者搞不清你指的是哪一个。
看到 rate limit exceeded 是额度用完了吗？
不一定。这个报错多数情况下是短时间内请求太密集触发了频率限制，等一会儿重试通常能恢复；而额度用尽一般会写成 quota exceeded 或 insufficient quota 这类措辞。两边处理方式完全不同，先分清再决定是等待重试还是去充值。
给海外团队写接口文档，用词上有什么要注意的？
尽量用对方平台后台里出现的原词，别自己意译。比如对方写 credit 你就别改成 balance，对方写 allowance 就别改成 quota。同时把周期和单位写进括号，比如「每月可用总量（次）」这种，避免对方按自己的习惯理解成别的口径。
