企业微信外部联系人相关接口出现超频，往往不是单点故障，而是调用方的并发模型与该接口的频控规则不匹配。常见诱因有三类：定时任务集中拉取、多个业务系统各自直连、异常后的无节制重试。解决思路不是简单加 sleep，而是先把调用量收敛到可控通道，再设计可观测、可退让的重试。下文按「场景 → 候选方案 → 代价与适用边界 → 决策建议」展开，并单独说明哪些情况不适合采用下述方案。
先判断超频的性质：瞬时尖峰还是持续过载
超频的处置方式取决于调用模式。瞬时尖峰是因为某个任务或某个操作在短时间内集中发起请求，持续过载则说明业务量与可用额度之间存在长期缺口。两者的处理方向不同，判断错了方案就会跑偏。
可以先从网关或调用日志里看调用分布，通常关注三个维度：
- 时间分布：请求是集中在整点、还是均匀铺开；峰值持续多久。
- 来源分布：同一时间段有多少个应用或定时任务在调同一个接口。
- 结果分布：返回的是频控类错误，还是超时、网关错误等，两者要区别对待。
若峰值只在短时间出现，优先做调用排队与合并；若全时段都接近上限，则要重新评估业务同步频率，把全量拉取改为按需查询或增量获取。需要把这类接口纳入统一治理时，可以参考我们的软件定制开发与系统集成服务里的接口层设计做法。
方案一：客户端令牌桶限流，分布式信号量控制并发
这个方案在调用方本地控制速率，用令牌桶设定平均速率和突发容量，用信号量限制同时在途的请求数。实现成本低，不与外部依赖耦合，适合调用点较少、部署相对集中的系统。
- 优点：改造范围小，通常只需在封装好的调用层统一加拦截；无需额外组件；对突发有缓冲能力。
- 限制：多实例部署时本地令牌桶各自独立，总速率会被放大，需借助共享存储做分布式令牌桶，否则容易出现「每个节点都不超、加起来超」。
- 适合：单一应用直连、调用点集中、峰值可预期的场景。
落地时建议把限流参数做成配置项，不写死在代码里。频控规则会随接口和账号调整，硬编码会导致每次变动都要发版。
方案二：服务端统一排队，所有调用走同一出口
把所有对外部联系人的调用收敛到一个统一的出口服务，由它负责排队、分发和额度分配。各业务系统只提交任务，不直接持有凭证。适合已经存在多个系统同时使用企业微信能力的组织。
- 优点：调用总量可见可控；凭证集中管理，减少泄漏面；额度可以在业务之间做优先级分配。
- 限制：引入一个必须保障可用性的中间层，需要为其做部署、监控和容量规划；业务方接入要改造，存在迁移周期。
- 适合：系统数量多、调用来源分散、需要长期治理的场景。
这个方案的关键不是排队组件选什么，而是定义清楚「谁可以插队」。建议给同步类任务和用户触发的实时操作分不同队列，实时操作的等待上限要明确，超限直接返回可理解的失败提示，而不是无限等待。
方案三：指数退避重试，带随机抖动与上限
重试机制本身不能解决超频，但能吸收短暂的频控波动。合理的设计是指数退避加随机抖动，并设置最大重试次数与总等待上限，超过就落库等待补偿。
- 优点：实现简单，对瞬时拒绝有明显缓冲；不改变整体调用模型。
- 限制：抖动不足会造成重试潮，反而放大峰值；无限重试会拖垮上游业务线程；不带状态的重试可能造成重复写入。
- 适合：读取类、可幂等重复的操作，或已有落库补偿链路的场景。
重试设计要和幂等一起看。对于新增外部联系人或打标签这类写操作，重试前必须先确认上一次是否已生效，否则容易产生重复数据。相关做法可参考更多技术实现细节中关于接口幂等与补偿的整理。
什么情况下不要选这些方案
以下情况说明问题不在限流与重试，改调用方式更有效：
- 业务本身要求持续全量同步。限流只会让同步周期拉长到无法接受，应改为增量获取或按事件驱动，而不是继续加排队。
- 调用来源无法收敛。若多个部门各自采购了不同系统且无法统一接入出口服务，强行建设统一网关容易成为职责不清的瓶颈，应先明确责任边界。
- 凭证权限过大。为图省事给所有系统共用一个高权限凭证，限流做得再好也无法阻止越权操作，应先把权限收窄。我们在同类项目案例中处理过类似的组织与权限梳理工作。
- 仅靠重试兜底。把异常都甩给重试队列、不做失败归因，问题会被推迟而非解决，长期会积累对不上的数据。
决策建议与文字版对比清单
多数场景下建议组合使用：统一出口负责总量与凭证，出口内部用令牌桶控速，失败按退避策略重试并落库补偿。选择的最小判据是调用来源数量与是否可集中部署。
- 客户端令牌桶限流 → 适合调用点集中、实例少的应用 → 主要代价是多实例下需共享状态，否则总量失控。
- 服务端统一排队 → 适合系统多、来源分散的组织 → 主要代价是多一个需要运维的中间层和接入改造。
- 指数退避重试 → 适合可幂等的读操作与短时波动 → 主要代价是无法提升额度，设计不当会放大峰值。
实施范围较大时，交付流程的梳理同样重要，可参考我们的服务范围与交付流程。
上线前自查清单
- 是否已统计调用来源，并确认每个来源都能被限流覆盖。
- 限流参数是否外置为配置，变更是否不需要发版。
- 多实例部署时，总速率是否按实例数正确折算。
- 重试是否有最大次数与总等待上限，是否有随机抖动。
- 写操作重试前是否校验前一次结果，是否具备幂等键。
- 失败任务是否落库并可在运维界面重放，重放是否有去重。
- 频控类错误是否与超时、网络错误分开告警。
- 是否预留了人工调低并发或暂停同步的开关。
常见问题
只加重试能不能解决超频？一般不能。重试只吸收短期波动，若调用量已长期超过额度，需要先降频或改变拉取方式。
限流阈值应该设多大？不宜凭经验拍板，应结合结果日志反推实际可用速率，留出一定余量，并随业务量定期复核。
是否一定要建统一网关？视系统数量和集成复杂度而定。只有一两个应用时，本地限流加水印更划算；来源分散、后续还要接入其他系统时，统一出口的长期收益更明显。
