NexCheck-筛号平台
很多人以为把一份号码名单拿去检测，最后会得到一个统一的“有效/无效”结论，实际上多平台号码检测的产出是一张状态矩阵：同一个号码在 WhatsApp 可能显示已注册，在 Telegram 却查不到，在 LINE 又可能是无效 User ID。
这份矩阵不是工具生成的，而是由各平台的应用层标识口径决定的。它真正要回答的不是“这个号码能不能用”，而是“这个号码在哪些平台有注册标识、哪些平台查不到、哪些平台需要再确认”。
本文结合 Telegram、LINE、WhatsApp 官方文档中的频控与错误码事实，回答四个问题：各平台检测的到底是什么、为什么结果不一致、不做前置检测会付出什么代价、以及结果矩阵如何设计并落库。
先看结论：多平台号码检测输出的是一张状态矩阵，不是一个有效/无效结论
一份号码名单跨平台检测后，应当得到“每平台一列状态”的矩阵，而不是一个布尔值。这样做是因为各平台的可检测对象并不一致，单一结论会掩盖关键差异。
从官方约束看，前置检测也是必须的：Telegram 对非付费广播的单聊限制为 1 条/秒，全局约 30 条/秒（Telegram 官方 Bots FAQ，2025-06）；LINE 明确禁止向不存在或无效的 User ID 滥发批量请求（LINE 官方 Messaging API 开发指南，2024-08）；Meta WhatsApp Cloud API 对单一接收者高频发送会触发配对限流（Pair Rate Limit），返回 429 与错误码 131056（Meta 官方错误码文档，2025-2026）。未做前置检测直接群发未注册号码，会迅速撞上这些限流，导致通道受限甚至风控降级。
各平台的标识口径不同：手机号、User ID 与 msisdn 分别指什么
“多平台号码检测”之所以复杂，是因为各平台拿到的标识对象并不一样：
| 平台 | 检测主体 | 标识格式 | 备注 |
|---|---|---|---|
| E.164 手机号 | 如 8613800138000 | 以手机号为主体，检测其是否注册 WhatsApp | |
| Telegram | chat/user 维度 | 账号 User ID 或手机号 | 检测手机号是否绑定 Telegram 账号 |
| LINE | User ID | 由 LINE 分配 | 检测 User ID 是否存在且有效 |
| Viber | msisdn | 标准 E.164 | 本文按 Viber Business Messages 以 msisdn 为标识、要求国际标准格式的通行做法处理；具体校验行为以 Viber 官方开发者文档为准，本文未引用其原文数值 |
Zalo 侧的公开开发者文档未完整披露第三方号码注册探测接口的限流数值，通常依赖本地生态合作方网关，因此本文不给出 Zalo 的口径与频控结论。
理解这张表，就能明白为什么同一份名单在不同平台的可检测对象并不一致：WhatsApp 和 Telegram 认的是手机号，LINE 认的是 User ID，Viber 则建议按国际标准 E.164 格式提交 msisdn。
为什么同一个号码在 WhatsApp 有标识、在 LINE 查不到：应用层状态互不继承
许多团队会问“WhatsApp 和 LINE 的号码检测结果为什么不一样”，根源在于四个状态层级互不等同：
- 格式合法：号码符合 E.164 国际标准。
- 运营商在网：号码分配给了运营商且当前可用（HLR 查询结果）。
- 平台已注册：号码在某个应用层创建了账号，可参考 号码注册状态检测。
- 账号活跃：该账号近期有使用行为。
应用层注册状态互不继承，这是多平台号码检测结果不一致的根本原因。
不做前置检测的代价：Telegram retry_after、LINE 429、WhatsApp 131056 分别在惩罚什么
各平台的频控与错误码惩罚的是不同行为：
| 平台 | 官方频控/错误 | 惩罚对象 | 官方来源 |
|---|---|---|---|
| Telegram | 全局约 30 条/秒，单聊 1 条/秒，群组 20 条/分钟；超限返回 429 并携带 retry_after | 发送频率 | Telegram Bots FAQ（2025-06） |
| LINE | Messaging API 明确禁止向无效 User ID 滥发，超出频控返回 429 Too Many Requests | 无效调用：向不存在或无效的 User ID 发送 | LINE 开发指南（2024-08） |
| 对单一接收者高频发送触发配对限流，错误码 131056；发信吞吐量默认 80 mps 可升级至 1000 mps；错误可同步 Graph 返回或异步 webhook 回传 | 同一号码的重复触达 | Meta 错误码文档（2025-2026） |
可以看到，Telegram 的 429 惩罚的是“发太快”，LINE 的 429 惩罚的是“发给无效 ID”，WhatsApp 的 131056 惩罚的是“对同一人反复发”。WhatsApp 侧的批量前置检测可参考 WhatsApp筛号平台。跳过前置检测，你就无法区分自己是被哪一个机制拦住。
跨平台清洗顺序：E.164 归一化 → 去重 → 分平台检测 → 结果分档 → 抽检复核
拿到一份号码名单，建议按以下五步顺序处理，顺序不能颠倒：
- E.164 归一化：把号码统一成国际格式（+国家码+号码），去除空格、括号、前导 0 等。这是所有平台检测的前提，Viber 侧建议按国际标准格式提交，可参考 手机号有效性检测。
- 去重：归一化后按国家码+号码去重，避免同一号码被重复检测浪费配额。
- 分平台检测：分别调用各平台的检测接口（如 WhatsApp、Telegram、LINE、Viber）。这一步可以并行，但要注意各平台的速率限制。
- 结果分档：把每个平台的结果分为“已注册”“未查到”“不可判定”“请求失败”四类。不可判定指账号状态不明（如隐私设置限制）；请求失败指网络或频控导致没拿到结果。
- 抽检复核：抽取 5%-10% 的样本，人工或二次检测验证结果的新鲜度，因为平台注册状态会随时间变化。
结果矩阵怎么设计字段并回写 CRM：每平台一列状态 + 检测时间戳
分平台检测得到的是一堆零散结果，必须落库为一张结构清晰的矩阵表。建议字段设计如下：
| 字段名 | 示例 | 说明 |
|---|---|---|
| normalized_number | 8613800138000 | E.164 归一化后的号码 |
| country_code | CN | 国家码 |
| whatsapp_status | registered / not_found / unknown / failed | WhatsApp 检测结果 |
| telegram_status | registered / not_found / unknown / failed | Telegram 检测结果 |
| line_status | registered / not_found / unknown / failed | LINE 侧 registered 表示 User ID 存在且有效 |
| viber_status | registered / not_found / unknown / failed | Viber msisdn 状态 |
| checked_at | 2026-07-15 10:30:00 UTC | 检测时间戳，用于判断数据新鲜度 |
| task_id | batch_20260715 | 本次检测任务标识 |
| fail_reason | rate_limit / timeout / parse_error | 请求失败时的原因 |
保留“未知”和“失败”状态非常重要——它们不是阴性结果，而是待重试或待人工确认的数据。同时必须记录检测时间戳，因为号码注册状态会变化（如用户注销、携号转网），一周前的“已注册”可能已失效。
在分平台检测到结果落库这一步，多套工具各自输出不同字段名和状态取值，会让拼接阶段出现口径错位。NexCheck 覆盖 WhatsApp、Telegram、LINE、Viber、Zalo 等平台的批量检测，可将多平台状态输出为统一结构，并提供 RESTful API 的批量提交、实时查询与 webhook 回调，适合放在分平台检测这一环节，减少格式转换与人工拼接成本。但请注意：检测结果只代表平台侧的注册标识状态，不代表可直接触达，也不替代 Opt-in 授权与发信端限流控制。
触达前仍需确认的两件事：Opt-in 授权与发信端的每联系人速率控制
前面的检测流程帮你筛出了“已注册”的号码，但这并不等于可以随意群发。
第一，营销触达仍需用户 Opt-in 授权。平台已注册不代表用户同意接收营销信息，未授权群发会引发高投诉率，导致账号永久封禁。
第二，发信引擎必须按平台配置每联系人的速率控制与退避重试。即使号码已注册，Telegram 的单聊限制仍然是 1 条/秒；WhatsApp 对同一接收者高频发送仍会触发 131056 配对限流。读取 Telegram 的 retry_after 参数，对 429 和 131056 做指数退避与幂等对账，是发信侧必须做的事。
结果与实际发送不一致时的排查顺序
当检测结果显示“已注册”，实际发送却失败时，可按以下顺序排查：
- 核对号码归一化是否一致
- 检查检测时间戳是否过期
- 区分同步 Graph 报错与异步 webhook 回传
- 确认是否命中配对限流或全局频控
- 抽样人工复核
- 判断是否属于“不可判定”态
常见问题
怎么知道一个号码有没有注册Telegram？
Telegram 侧检测的是 chat/user 维度的注册标识，而不是手机号本身。受用户隐私设置影响，部分账号即使已注册也只能返回“不可判定”。具体做法可参考本文第五节的清洗流水线（归一化→去重→分平台检测→结果分档）。
WhatsApp和LINE的号码检测结果为什么不一样？
因为两个平台使用的标识不同：WhatsApp 以手机号为主体，而 LINE 以 User ID 为主体。同一个手机号在 WhatsApp 有注册，但在 LINE 上没有对应 User ID，所以结果自然不同。这反映了应用层注册状态互不继承的特点。
LINE Messaging API 429 Too Many Requests 是什么原因？
429 表示请求频率超出限制，或者你向无效的 User ID 发了消息。LINE 官方明确禁止向不存在或无效的 User ID 滥发请求，因此遇到 429 时应检查目标 User ID 是否有效，并降低发送频次。
Telegram Bot API retry_after 怎么处理？
retry_after 是 Telegram 返回 429 时给出的等待秒数。正确做法是：收到 retry_after 后暂停该聊天下一步发送，至少等待相应秒数再重试。同时要遵守单聊 1 条/秒、全局约 30 条/秒的限制，合理控制整体节奏。
Viber 的 msisdn 一定要 E.164 格式吗？
Viber Business Messages 以 msisdn 作为接收方标识，行业通行做法是提交国际标准（E.164）格式的号码；本文未引用 Viber 官方文档原文，具体校验规则与失败返回请以 Viber 官方开发者文档为准。因此，在批量检测前，务必把号码统一为国际格式，例如中国号码写成 8613800138000，而不是 13800138000。
多平台号码检测和运营商在网查询有什么区别？
运营商在网查询（HLR）回答的是“号码是否分配且在网”，属于通信层状态；多平台号码检测回答的是“号码是否注册了某个社交应用”，属于应用层状态。两者不能互相替代：一个在网的号码可能没注册 WhatsApp，一个注册了 LINE 的号也可能已停机。
先用一份 200–500 条的小样本，在 NexCheck 或你现有的检测通道上跑完“归一化→去重→分平台检测→抽检复核”，确认各平台状态列的口径和数据新鲜度符合预期，再决定是否把全量名单接入自动化流程。
评论(0)