「外部群能加多少人」「群发一次能发多少」这类问题的答案会变 —— 随企业认证状态、账号状态和平台策略调整。所以把某个数字抄进代码是最脆弱的做法。更有用的是先把限制分类：哪些是可预知的容量上限、哪些是动态的速率约束、哪些是根本不会告诉你阈值的行为约束。这三类的应对方式完全不同，混着处理就会一直在补救。下面的应对做法按 wecomapi 的接口调用与频控反馈来写。
先把限制分成三类
大部分「被限制了」的排查最后都会发现，根因是把三类性质完全不同的约束当成同一件事在处理 —— 用重试去解容量问题，用加账号去解参数问题，都是这么来的。
- 容量类硬上限：单个群的人数上限、可维护的群数量。特点是确定、可预知、变化慢。应对方式是在设计阶段就分片，而不是运行时补救。
- 速率类频控：单位时间内的调用与发送次数。特点是动态、与账号状态相关、命中时通常有明确反馈。应对方式是排队、限速与退避。
- 行为类约束：短时间内高度集中的同质操作。特点是不给你阈值，表现可能是延迟、降级或部分不生效。应对方式是控制节奏、分散负载，并且只能靠自己的监控发现。
判断一次失败属于哪一类，看三个信号就够：有没有明确的失败反馈、失败会不会随时间自动恢复、同样的操作换一个账号是否还失败。三类在这三个信号上的组合各不相同，分清楚之后应对手段基本就定了。
三类里最容易出事的是第三类，因为它不报错。你的监控如果只看 HTTP 状态和失败率，会完全看不见它 —— 直到运营告诉你这周的群里没人说话。
容量类：群位是一种要提前规划的资源
外部群人数上限具体是多少，随企业认证状态与官方规则调整而变化，写死在代码里迟早会错。真正值得固化下来的不是那个数字，而是「快满了怎么办」这套逻辑。
常见做法是群池：一个主题（活动、区域、产品线）对应一组群，新成员按剩余群位路由到其中一个。这里有个取舍要先定下来：是提前把二十个空群铺好，还是满一个开一个？
建议后者。空群的成本不是零 —— 每个群都要维护群名、公告、机器人和群发内容，运营成本随群数线性增长，而稀群的活跃度和转化通常明显低于满群。提前铺群唯一的好处是路由时不用等建群，而这个好处用「剩余群位低于水位就异步预建下一个」就能拿到，不需要一次铺开。
- 给群池维护一个「剩余可用群位」的水位，低于水位就调 wecomapi 的建群接口异步预建，而不是等到真的满了才反应。
- 路由策略优先填满一个群再开下一个，不要均匀摊平 —— 群的价值来自密度，摊平只会得到一堆半死的群。
- 上限数值做成配置项，不要散落在业务代码的判断里；官方规则调整时只改一处。
人数上限、群数量这类具体数值以企业微信官方规则为准，并且要按你自己企业的实际状态核实一遍，不要照抄任何二手描述，包括本文。
速率类：分批与分时，重点在「怎么定批」
分批不是把一万条切成一百批就完事。批的大小和批之间的间隔是两个独立参数，定错任何一个，效果都不对。
批大小由两件事共同决定：单批失败的爆炸半径（一批失败要重来多少工作量），以及你希望多久拿到一次反馈信号。批太大，一次失败要重跑很久，而且等你发现问题时已经发出去很多了；批太小，调度开销和监控噪声都会上升。让一批在几分钟内跑完、失败可以整批重来，通常是个合适的量级。
批级重试有个前提常被忽略：每条投递项必须幂等。整批重来意味着已经成功的那部分会再走一遍，如果投递项没带业务唯一键、发送侧不做去重，「重来一批」就等于「多发一批」，客户收到两条一样的内容比没收到更糟。
批间隔则不该是固定值。固定间隔假设系统状态不变，而真实情况是账号状态、平台负载都在变。更稳的是让间隔跟着 wecomapi 返回的频控反馈走：连续成功就缓慢缩短，命中频控就立刻拉长，并且拉长要比缩短激进得多 —— 降速要快，提速要慢，这条在所有自适应限速里都成立。
分时是另一个维度，而且它不只是为了频控。深夜或高峰时段的群发，代价往往不是被限制，而是退群和屏蔽 —— 这个代价比等一个小时贵得多。把「允许投递的时间窗」做成一等公民：任务生成时不指定具体发送时刻，只指定可投递窗口，超窗的投递项自动顺延到下一个窗口。
行为类：分号是分摊，不是加倍
多账号是应对行为类约束最有效的手段，也是最常被用错的一个。用错的形态很好认：为了发得更多而加号，然后让每个新号立刻满负荷跑批。
这么做有两个问题。一是新账号没有真实的使用历史和客户关系，一上来就承担高强度批量任务，与正常业务使用的本来也不该产生这种量级的动作；二是所有账号跑同一套节奏，等于把单账号的风险模式复制了 N 份，一出问题就是 N 个号同时出问题，冗余等于没有。
更稳的模型是给每个账号一份预算，调度按剩余预算选号，而不是简单轮询。
// 示意逻辑：新账号、近期在 wecomapi 上命中过频控的账号，预算自动更低
function pickAccount(accounts, task) {
const usable = accounts
.filter(a => a.status === "healthy")
.filter(a => a.inWindow(task.now)) // 在允许投递的时段内
.filter(a => a.remainingQuota(task) > 0);
if (usable.length === 0) return null; // 没号就排队，不要硬发
// 选剩余预算比例最高的，让负载自然摊开而不是集中在头几个号
return usable.sort((x, y) => y.quotaRatio() - x.quotaRatio())[0];
}预算的账要记在账号上，不要记在业务线上 —— wecomapi 的一个企业微信账号对应一个独立实例，频控与行为约束都落在这个粒度上，而一条业务线常常横跨好几个实例；按业务线记账，某个实例被几条业务同时打满时，哪一处都看不出来。预算本身要随账号的存续时间和真实使用情况逐步放开，新号从很低的额度起步。这不是保守，是让账号的使用强度和它真实的业务背景保持一致 —— 一个刚建立、还没有多少客户关系的账号，本来也不该产生大量群发。
没有可用账号时的正确行为是让任务排队等待，而不是降级到某个「看起来还能用」的账号上硬发。前者只是慢，后者会把问题从一个号扩散到两个号。
怎么知道自己撞到了限制
撞到速率限制通常有明确反馈，不难发现。真正麻烦的是行为类约束下的静默异常：调用全部成功，但消息的实际到达和群内互动明显下滑，指标要过几天才看得出来。
- 给每类失败打分类标签（参数错误 / 权限 / 频控 / 其他），各自单独出趋势图。频控占比的抬头往往比总失败率更早报警。
- 监控「成功但无后续」的比例：发出去了、群里长时间没有任何互动事件，这是需要人看一眼的信号。
- 所有指标都要按账号维度看，不要只看全局。全局平均会把单个账号的异常稀释到看不见。
- 提速、加号、改文案、扩批次这类变更必须留记录。出现异常时第一件事是对时间线，没有变更记录就只能靠猜。
本文讲的是把限制当成设计约束的工程做法。具体的人数上限、频率阈值与失败反馈以企业微信官方规则和 wecomapi 线上接口文档为准，示意代码只表达结构，不代表任何接口的实际行为。
常见问题
- 企业微信外部群人数上限是多少？
- 这个数值随企业认证状态与官方规则调整而变化，不适合写死在代码里，应以企业微信官方规则和你自己企业的实际状态为准。工程上更该固化的是「接近上限怎么办」：给群池设一个剩余群位水位，低于水位就异步预建下一个群，上限数值只作为一处配置存在。
- 群发被限制了，能靠重试解决吗？
- 看是哪类失败、怎么重试。wecomapi 返回的频控失败属于可重试的一类，前提是退避加随机抖动；固定间隔的定时重试会让同一批失败任务在同一时刻集体重来，比第一次更集中。参数或权限类失败重试多少次都不会成功，应该直接进死信队列由人来看。
- 多准备几个账号就能多发吗？
- 方向对，用法容易错。多账号的作用是把负载摊开并提供冗余，不是把总量按账号数直接乘上去。新账号应从很低的预算起步、随真实使用逐步放开，调度按剩余预算选号而不是轮询；没有可用账号时让任务排队，而不是硬塞给某一个账号。算账时也注意，加号加的是订阅成本不是调用成本 —— wecomapi 按账号订阅、订阅内可无限次调用接口、不按调用次数计费（适用公平使用策略），所以账号数该由业务上真需要几个身份来定；把它当成放大发送总量的旋钮，结果多半是几个号在同一天一起出问题。
准备好动手了？
精确字段、鉴权与端点以线上文档为准；可在控制台创建密钥后联调。