批量号码验证别只看有效无效，结果要按多列落库

执行批量号码验证时，第一步必须明确输出结构需包含平台维度、三档状态及原始错误码，而非简单的布尔值。只有建立这种多列映射机制，才能确保后续数据能准确对回客户主档中的具体人员，避免验证跑完却无法复用的困境。

先问用途再问标识：批量号码验证结果的判断路径

在决定存储格式前，需厘清这批数据的最终去向。若仅用于发信前的即时过滤，结果停留在“可触达/不可触达”的状态列即可；但若需长期沉淀至SCRM系统，则必须补齐平台列、精确的时间戳以及批次号，以便追溯数据来源。

更为关键的是标识符的归属。拿到的若是标准的 E.164 国际电话号码，可直接作为主键匹配；但如果是 WhatsApp 等平台内部的匿名标识（如 @lid），则不能直接写入手机号字段，必须进入反查与映射分支处理。此外，对于接口返回模糊或超时的记录，应标记为“未知”并放入复检队列，严禁将其直接判定为“无效”从而误删潜在高价值线索。

回流消息只带 @lid 不带手机号时怎么补回身份

WhatsApp 引入的 @lid 机制旨在保护用户隐私，但这给企业侧带来了识别断层。当客服或营销系统收到带有 @lid 的消息时，无法直接获取对应的手机号，导致这条互动记录无法自动关联到 CRM 中已有的客户档案。

为解决这一身份缺失问题，服务商提供了 LID 转手机号的查询能力。根据 Whapi.Cloud 在 2026 年 8 月底发布的更新日志，该反查操作已被正式计入号码检测额度（phone check limit）。这意味着每一次尝试将匿名 ID 还原为明文号码，都会消耗相应的 API 配额。

在处理此类请求时需区分错误类型：若返回 404，表示该 @lid 尚未建立映射关系，系统应保留原始 @lid 等待后续补全，而不是丢弃记录；若返回 502，通常属于网关临时故障，应按指数退避策略重试，且不应修改号码的状态列。无论哪种情况，这两类请求均需单独计入额度对账表，防止因频繁重试未映射记录而意外耗尽检测配额。

131026 不能压成一档：把成因拆成独立字段

Meta 官方文档指出，错误码 131026（Message Undeliverable）并非单一指向“号码未注册”。其成因复杂，包括号码确实非 WhatsApp 账号、用户未接受最新的服务条款与隐私政策，或是客户端版本过低。若将这些情况统统压缩为“无效”，会导致大量本可通过引导更新或重新授权激活的用户被误杀。

正确的落库做法是：状态列仅标记为“未确认可达”，同时在数据库中增设“错误码”与“成因备注”列，完整保留 API 返回的原始信息。这为后续的精细化运营提供了依据，例如针对“未接受条款”的用户发送合规提醒，而非直接拉黑。

需注意区分 131056 错误码，它代表配对速率超限（每个接收者每 6 秒限发 1 条，突发上限 45 条且会借用未来额度）。这是触达节奏控制问题，而非号码本身的状态问题，绝不应混入号码状态列，以免干扰对客户质量的评估。

未知档单独一列：PHONE_NOT_OCCUPIED 的两种可能

Telegram 的隐私机制进一步证明了“二值逻辑”的缺陷。当调用 contacts.resolvePhone 接口时，如果目标号码未注册，或者用户在隐私设置中开启了 inputPrivacyKeyAddedByPhone 限制（禁止通过手机号查找），接口均统一返回 PHONE_NOT_OCCUPIED。

由于 Telegram 官方要求客户端实施频控防抖，最多每 3 秒发起一次调用，且 Bot 无权执行此方法，这使得批量探测的成本较高且存在盲区。因此，在数据库设计中，“已注册”、“未注册”和“未知”必须是同一列的三个独立取值。

对于“未知”档，建议记录返回原文与检测时间，并将其纳入定期复检排期。在生成 CRM 触达名单时，默认排除“未知”档用户，但需在系统中保留其可召回状态，待隐私策略变更或技术突破后再行评估，避免因过度清洗导致潜在客户流失。

跨平台合并主键选谁：E.164 号码与平台内标识的对应

在多平台数据融合场景中，归一化后的 E.164 号码通常作为跨平台合并的主键，而各平台内部 ID（如 WhatsApp @lid、Telegram UID）则作为从键，用于维持特定渠道的身份映射。导入时的原始 ID 与批次号则用于回溯数据来源行，确保数据血缘清晰。

然而，号码归一化并非无脑删除前导零。虽然多数国家适用“国家码后首位 0 一律删掉”的规则，但意大利等国的地理区号本身以 0 开头，强行删除会导致号码失效。部分非洲国家的最新编号方案也存在特例。因此，改写规则必须按国家维度维护配置表，并在数据库中始终保留“原始号码”列，以防归一化逻辑出错时有据可查。

两个平台结论打架时的判定顺序与主档字段表

当同一个人在不同平台上的验证结果出现冲突时，需要一套明确的判定顺序。首先比较检测时间戳，取最新的结论；若时间接近，则按平台分列存放，不强制覆盖为一个全局状态；若一方为“未知”，另一方为明确结论，则以明确结论为准并保留未知记录；若两个明确结论互斥（如 A 平台显示未注册，B 平台显示活跃），则遵循“本平台结果只作用于本平台触达决策”的原则，不进行跨平台状态同步。

为实现高效的数据对齐，NexCheck 支持 WhatsApp、Telegram、LINE、Viber、Zalo 等 100+ 平台的批量筛选，并提供 RESTful API 支持批量提交、实时查询与 webhook 回调。通过其标准化的输出，多平台状态可以以同一套字段口径呈现，大幅减少了自行开发字段转换脚本与主键对齐的工程负担。但需明确，检测结果仅解决注册存在性，不替代用户的 Opt-in 授权，也不保证平台规则不会发生变更。

回写 CRM 后的核对清单：抽检、复检排期与授权确认

数据回写完成后，需执行以下核对步骤以确保质量：

1. 完整性检查：随机抽取记录，确认每条都包含平台列、状态列、检测时间戳与批次号，缺失字段的记录需立即隔离。
2. 人工复核：对“已注册”与“未注册”各抽取固定比例（建议团队自定，如 5%）进行人工比对，记录两轮检测的不一致率，以此校准工具准确度。
3. 未知档管理：将“未知”档单独列入复检队列，按批次而非逐条重试，避免触发 API 频控。
4. 映射追踪：对于 @lid 未映射的记录，保留原始标识并监控后续映射成功率，同时核对反查次数与检测额度的消耗是否匹配。
5. 授权确认：在生成最终触达名单前，再次校验这些号码是否拥有有效的 Opt-in 授权来源与时间，确保合规性。

常见问题

批量号码验证的结果表里到底该有哪些列？

除了基础的手机号，必须包含平台标识、三档状态（已注册/未注册/未知）、原始错误码、检测时间戳和批次号。若涉及 WhatsApp，还需预留内部 ID（@lid）字段。缺少任何一项都可能导致后续 CRM 合并时无法追溯原因或匹配失败。

收到的消息只有匿名标识、没有手机号时该怎么和老客户记录对上？

需通过服务商提供的 LID 转手机号接口进行反查。注意此操作通常会计入检测额度。若返回 404 表示暂无映射，应保留 @lid 等待后续更新；若返回 502 则是网络波动，需重试但不改变状态。切勿直接丢弃未映射的记录。

反查手机号会不会额外消耗检测配额？

是的，根据 2026 年 8 月的行业更新，LID 转手机号的查询已被纳入号码检测额度（phone check limit）。高频的反查重试会加速配额消耗，建议在代码层面对 502 错误实施指数退避重试，并对 404 错误做去重处理，避免无效轮询。

查不出结果的那部分号码要不要写进CRM、写成什么？

应当写入，但状态需标记为“未知”或“Pending”。不要将其误判为“未注册”而剔除。在 CRM 中，这类号码默认不参与自动化触达，但应保留在数据库中，设定定期复检计划，因为隐私设置或用户行为可能会随时间改变。

同一个人在两个平台状态不一致时以哪一条为准？

不存在绝对的“准”，应遵循“平台隔离”原则。即 WhatsApp 的状态仅影响 WhatsApp 触达，Telegram 的状态仅影响 Telegram 触达。若必须合并，优先采信检测时间更近的记录；若时间相近且冲突，则在 CRM 中分别展示各平台状态，由运营人员人工判断。

多平台筛号结果怎么合并成一个客户？

以归一化的 E.164 号码为主键进行合并。务必保留各平台的原始 ID 和各自的验证状态。对于不同工具输出的异构数据，需先统一字段口径（如将 True/False 转换为 Registered/Unregistered），再执行 Upsert 操作，避免新数据覆盖旧的有效历史状态。