结论先给：额度是总量（一共能用多少），限流是速度（单位时间内能用多快）。额度用完的表现是余额接近 0、提示额度不足；被限流的表现是余额还有、但短时间请求被拒或变慢。先看额度页的数字，就能分辨。
一句话区分
| 额度 | 限流 | |
|---|---|---|
| 管什么 | 总量 | 速度/频率 |
| 用完的样子 | 余额接近 0 | 余额还有但请求被拒 |
| 怎么恢复 | 等政策/换账号 | 等一段时间再试 |
| 看哪里 | 额度页数字 | 短时间是否高频 |
怎么分辨
看余额
额度页还有余额 → 更像限流；接近 0 → 额度见底。
看频率
刚才是否短时间连发很多次？是 → 更像限流。
等一会再试
隔几分钟再发一次就通了 → 限流；仍然不行 → 查额度。
各自怎么办
- 额度见底：把额度留给关键任务，参考 额度用完之后。
- 被限流：降低请求频率，间隔发送，别高频重试。
- 两者叠加：既快用完又频繁请求，会同时触发，先降频再谈额度。
为什么容易搞混
两种问题的表层现象都是「用不了」，但原因和处理完全相反：额度问题要省着用，限流问题要慢下来。搞反了就会越试越糟——比如把限流当成额度用完，反而更频繁重试。
常见问题
额度还有却用不了，是限流吗？
很可能。余额还有但短时间请求被拒，符合限流的特征。
限流会持续多久？
通常是一段时间内自动恢复，降频后更容易恢复。
频繁重试能更快恢复吗？
不能，反而可能加重限流，应间隔发送。
额度用完也会表现为变慢吗？
可能，但更典型的是提示额度不足、余额接近 0。
相关页
一张对照表
| 维度 | 额度 | 限流 |
|---|---|---|
| 限制对象 | 总量 | 单位时间内的速度 |
| 典型提示 | 额度不足 / 已用尽 | 请求过快 / 请稍后再试 |
| 恢复方式 | 补充或等周期重置 | 降频后很快恢复 |
| 受影响范围 | 持续到额度恢复 | 通常是短时 |
为什么容易混淆
两者都可能表现为「突然不能用」或「变慢」，所以常被当成同一件事。区别主要在恢复方式：额度用完要靠补充或等待周期重置；限流通常在降频后很快恢复。
三步排查
- 看提示文案：是「额度不足」还是「请求过快」。
- 看时间：几分钟内恢复 → 更像限流；长时间不变 → 更像额度。
- 看形态：单次长请求被拒 → 更像限流；连续用到某个量后停 → 更像额度。
一分钟自测：你现在是哪种
| 问自己 | 答「是」→ 更像 |
|---|---|
| 等 5 分钟再发同一个问题，成功了吗？ | 限流 |
| 换个更短的问题，成功了吗？ | 额度或上下文 |
| 账号里显示的用量还在涨吗？ | 还在涨＝额度没用完 |
为什么这两个概念容易被混
- 两者都会让你「发不出去」，但一个是速度问题、一个是总量问题。
- 限流被拒的请求通常不计费；额度不足则根本没走成。
- 处理方式相反：限流要等，额度不足要补。
两个真实场景，走一遍就清楚了
场景一：你连着问了 8 个问题，第 9 个被拒。等 3 分钟再问同样的第 9 个问题——成功了。这是限流：你发得太快，系统让你缓一缓。处理办法只有一个：降频。跟额度无关，也不用换账号。
场景二：你换了 3 个短问题都被拒，等 10 分钟还是被拒，而且账号里显示的用量不再变化。这更像额度已用完：请求根本没走成。处理办法是补额度，不是等。
两者的差别可以用一句话记：限流是「等一下」，额度是「没有了」。
把限流当成额度用完——两者机制不同。
把额度还有当成不会限流。
遇到报错就归因到其中一个。
自检清单
最后核对：2026-10-08。内容来自公开分享与我们的核对；具体提示文案随服务变化。
出处：本页是公开信息与社区说法的整理（定义 / 对照），不是我们亲测的步骤；有分歧处两种都保留。涉及金额、时限的数字按「社区口径」处理，最终以 App 内为准。核对时间 2026-09～10。
这些会变：入口位置、额度、政策。以页面顶部的「最后核对」日期为准，日期旧了就当参考。
邀请码来自网络公开分享：HUZM98，不填也能用，填了双方各得额度。以注册后 48 小时内、App 内显示为准。