NexCheck-筛号平台
WhatsApp号码批量检测怎么分批，取决于检测侧的队列吞吐与失败重投余量，而不是发信配额。发信节奏另有一套配对限流预算，两者必须分开算。Meta 在 2026-08-04 的 WhatsApp Business Platform 官方文档中，将配对频控（Pair rate limit）明确为每个用户每 6 秒 1 条（约 10 条/分），突发（burst）最多 45 条但会借用未来配额。
两条速率线要分开：检测批次的节流，和发信批次的配对限流
最常见的排产误区，是把检测并发当成发信预算来算。检测侧受制于你所用的检测服务的任务并发与退避策略，发信侧受制于平台官方对“企业号码—单个用户”这一对关系的配对频控。两者的计量单位、触发对象和惩罚方式完全不同：多平台号码检测限流对照 可作参考：
| 维度 | 检测批次 | 发信批次 |
|---|---|---|
| 计量单位 | 任务并发、单批完成时长 | 每条消息间隔、burst 上限 |
| 触发对象 | 检测服务的接口限额 | 同一企业号码与同一用户的配对关系 |
| 惩罚方式 | 检测 API 返回限流响应、要求退避重试 | 直接触发 131056 错误码，持续违规会降级 |
| 预算来源 | 所选服务的任务队列吞吐 | 平台配对频控（6 秒 1 条、burst 45 条） |
并发指同时在途的任务数，吞吐指每秒实际完成数，切批用吞吐算，退避策略用并发控。看清这条分界线，后面的三笔账才立得住。
第一笔账：WhatsApp号码批量检测怎么切批——单批规模、并发上限与重投余量
WhatsApp号码批量检测的切批口径不是“越多越好”，而是由“可接受的单批完成时长 × 稳定吞吐”反推单批规模，并且强制预留失败重投余量。建议按批内 5%–10% 的比例预留，而不是把配额跑满。
- 单批规模 =（稳定吞吐 × 期望单批完成时长）×（1 − 重投余量比例）
- 例如：稳定吞吐为 10 任务/秒，期望 10 分钟跑完，重投余量 10%，则单批规模约为 10 × 600 × 0.9 = 5400 条。余下的 10% 容量留给失败重投，避免重试请求把当批配额顶穿。
单批不宜切得过大，否则回调聚合与落库压力叠加，容易拖垮处理进程；也不宜过小，否则调度开销占比过高，整体吞吐上不去。具体并发与吞吐上限，以你所用的检测服务实际返回的限流响应为准，本文不给出未经证实的固定数值。
第二笔账（重点章节）：配对速率 6 秒 1 条、burst 45 条借用未来配额意味着什么
这是最容易算错的一笔账。Meta 官方 2026-08-04 文档规定，企业号码向同一 WhatsApp 用户发信的配对频控为每 6 秒 1 条（约 10 条/分），突发（burst）最多 45 条，但会借用未来配额；一旦超限，直接触发 131056 错误码。
“借用未来配额”意味着 burst 用完后，同一用户的可用速率会被提前透支。也就是说，burst 不能当作常态吞吐来规划，你在这个时间窗口内发得越快，接下来能等的空闲时间就越长。发信窗口的倒推公式是：
- 每用户发信窗口 =（计划触达条数 ÷ 10 条/分）× 60 秒
- 若单个用户计划发 3 条，则至少需要 18 秒的窗口，且不能在第 1 条后立刻连发 3 条（burst 里包含这 3 条，但用完后要等未来配额恢复）。
记住，配对限流针对的是“企业号码—单个用户”这一对关系，与名单总量是两回事。所以就算你名单里有 5 万个用户，每个用户之间的发信节奏彼此独立，并不会因为总量大而整体加速。
第三笔账：131026、131056、131048 各自在惩罚什么，该改哪个参数
三个错误码对应三个不同的调参动作，别混在一起改：
| 错误码 | 触发场景 | 该改的参数 |
|---|---|---|
| 131026 | 向非 WhatsApp 用户或未接受隐私协议用户发信 | 名单质量与前置检测覆盖率 |
| 131056 | 配对速率超限 | 发信节奏与 burst 使用 |
| 131048 | 账号发送行为被平台整体限制（官方归入限制类，未公开细分判定口径） | 发送总量节奏、模板合规与 Opt-in 覆盖，需结合 WABA 后台状态排查 |
官方明确指出，高频无效发送会直接导致 WABA Quality Rating 降级。这正是“检测通过但质量评分还是掉了”的排查起点：检测只解决 131026 那一类，解决不了速率与合规两类。
合成一张排产表：名单量、检测窗口、发信窗口怎么倒推
把三笔账合成一张可落地的排产表，WhatsApp号码批量检测的窗口就能直接算出来。倒推顺序是先定发信窗口，再定检测截止时间，而不是检测跑完才开始想发信节奏。
| 输入项 | 示例值 | 输出项 | 计算值 |
|---|---|---|---|
| 名单总量 | 50,000 条 | 单批规模 | 5,400 条/批 |
| 单批规模 | 5,400 条 | 批次数 | 10 批（向上取整） |
| 稳定吞吐 | 10 任务/秒 | 检测窗口 | 10 批 × 10 分钟 = 100 分钟 |
| 重投余量 | 10% | 可开始发信时间点 | 检测开始后 100 分钟 |
| 每用户计划触达条数 | 3 条 | 单用户发信窗口 | 18 秒（3 条 ÷ 10 条/分） |
| 有效用户数（假设 80% 通过） | 40,000 | 全量发信窗口 | 有效用户数 ÷ 系统实际并行发送能力 × 单用户窗口 |
全量窗口取决于并行发送能力，不是把单用户窗口逐个相加；配对限流不会因名单总量变大而收紧。如果你的发信窗口只有 2 小时，那就得把“每用户计划触达条数”降到 1 条，或者延长整体发信周期，而不是去提高检测并发。
结果落库口径：为什么“未知”档必须保留，重跑放下一批而不是当批重试
批量检测结果不能做二元布尔判断。社交账号注册检测三档结果 一文说明，注册检测的结果应分为“已注册”“未注册”“未知”三档。Telegram 官方协议（2026-05-15）提供了一个跨平台佐证：contacts.resolvePhone 要求最少 3 秒 1 次的 debounce，且未注册与开启 inputPrivacyKeyAddedByPhone 隐私保护的用户返回完全相同的 PHONE_NOT_OCCUPIED，无法区分。
由此推出的通用工程结论是：限流与隐私导致的不确定必须落成独立的“未知”档；当批立即重试只会继续撞退避，应排入下一批次窗口。同时要记住，“号码已注册”不等于“可触达”，更不等于“已获授权”。
检测批次与发信批次解耦的实现：队列、批次号、时间戳与幂等键
工程实现上，建议把检测任务走异步队列，用批次号 + 号码归一化值组成幂等键，并记录提交时间戳与回调时间戳，以便复算实际吞吐。这样检测吞吐与发信侧配对速率就是两套独立预算，互不污染。
检测侧队列可以自建，也可以直接用支持批量提交与 webhook 回调的检测 API 承担，例如 NexCheck 的 RESTful API。具体步骤是：
- 按批次号提交号码列表，记录提交时间戳。
- 通过 webhook 接收每条结果，用批次号 + 号码归一化值作为幂等键写入结果表。
- 回调完成后，按批次号回写 CRM，标记该批次的状态（已完成 / 部分未知）。NexCheck 的回调结果字段按批次号回写 CRM 后，检测吞吐与发信配对速率就是两套彼此独立的预算。
这样检测环节的并发压力不会误算进发信预算。检测服务的选型口径见WhatsApp筛号平台怎么选，批量号码检测API 的集成方式也类似，核心是解耦。
跑之前的两项前置：Opt-in 授权与模板合规不能被检测结果替代
发信成功率和防封取决于 Opt-in 授权、模板合规、配对限流与用户拉黑率。注册检测只能确认号码在平台上的状态，不能替代授权与质量评分控制。所以“筛号通过即可随意群发且防封”的说法不成立。
常见问题
一次能批量检测多少个号码？
取决于你所用检测服务的任务并发与单批完成时长。用“稳定吞吐 × 期望时长”反推单批规模，建议预留 5%–10% 重投余量。例如并发吞吐 10 任务/秒、期望 10 分钟、预留 10% 重投余量，单批约 5,400 条。没有固定上限，以服务实际返回的限流响应为准。
WhatsApp Cloud API 131056 怎么解决？
131056 是配对速率超限，说明你向同一用户发得太快。立即停止对该用户的发送，等待 6 秒/条的速率恢复。若已触发 burst 45 条，需等待未来配额恢复，通常建议拉长间隔，并检查是否把 burst 当常态用了。
131026 是什么错误？
131026 表示你向非 WhatsApp 用户或未接受隐私协议的用户发信。解决办法是提升名单质量，加强前置检测覆盖率，把这类号码从发信列表剔除。这是检测能解决的主要错误码。
WhatsApp给同一个人发消息间隔多久不会限流？
官方规定是每 6 秒 1 条，即约 10 条/分。给同一个人发消息，建议间隔至少 6 秒，突发最多 45 条，但会借用未来配额，所以不能持续用 burst 频率。
批量检测跑完多久可以开始群发？
检测完成后，先确认结果已落库并筛选出“已注册且已授权”的号码，然后按配对速率倒推发信窗口。如果每个用户计划发 3 条，至少需要 18 秒/人，所以实际等待时间取决于你计划的触达节奏，而不是检测完成本身。
WhatsApp burst 45条用完会怎样？
burst 45 条用完并不代表当天配额耗尽，而是会借用未来配额，因此后续同一用户的发送速率会被压低，可能触发 131056。建议把 burst 当作应急手段，不要作为常态吞吐规划。
检测通过但质量评分还是掉了怎么排查？
先看最近的错误码分布：如果 131026 多，说明检测覆盖不足；如果 131056 多，说明发信节奏过快；如果 131048 多，说明整体行为受限。检测只能解决 131026 那一类，速率与合规需要靠发信策略和 Opt-in 管理来调整。
评论(0)