使用场景指南
安全清洗 Telegram 联系人名单的流程
可靠的 Telegram 名单清洗应保留来源记录、规范手机号、识别重复项、检测注册状态、区分完成的 false 与可重试失败，并将技术结果与同意和抑制规则结合。
审核日期：2026 年 7 月 21 日
清洗后的联系人记录应包含什么？
保留原始号码、E.164 规范值、规范化状态、完成的 Telegram 结果或重试状态、检测时间和最终路由决策。输入无效、registered=false 与临时服务失败需要不同动作，不能共用一个“无效”值。
建立分阶段且可逆的流程
每个阶段增加结构化证据，同时保留用于纠错的原始值。
- 1
保留来源
为每行分配稳定 ID，并保留原始号码、来源、导入时间和国家信息。
- 2
规范化并去重
生成 E.164 值，标记有歧义记录，并按规范号码识别重复项。
- 3
运行 service_type=tg
每个同步请求发送一个规范号码，并保存每条已完成记录。
- 4
分类结果
分别保存已注册、未注册、输入无效、可重试与余额阻断。
- 5
应用路由政策
任何触达前结合同意、抑制名单、接收方偏好与适用规则。
建议的输出字段
结构化输出可支持定向重试和审计，避免重复检测已完成记录。
| 字段 | 作用 | 示例 |
|---|---|---|
| source_phone | 保留导入值 | +1 (415) 555-2671 |
| normalized_phone | 规范请求与去重标识 | +14155552671 |
| normalization_status | 区分有效与有歧义输入 | valid / needs_review |
| verification_status | 区分完成判断与运行状态 | registered / unregistered / retry |
| verified_at | 标记时点判断 | ISO 8601 时间 |
| routing_decision | 记录动作与原因 | keep / suppress / review |
处理名单时遵守同步限制
API 每次接收一个手机号，应使用有界任务队列，而不是一次释放整个文件。
- 每个用户最多保持 3 个在途检测。
- 网页后台与 API 合计不超过每分钟 200 次。
- 429 不扣余额；等待窗口或并发名额恢复后自行重试，503 或无判定稍后重试。
- 除非需要更新状态，不要重试已完成的 registered=false。
- 保存进度，使中断任务无需重复完成行。
注册状态不是触达许可
已注册结果能够改善路由数据，但不能证明身份、合法用途或同意。
- 在规范化后应用退订与抑制名单，避免格式差异绕过规则。
- 仅向确有需要的系统导出手机号与结果字段。
- 按工作流设置复核周期，不假设结果永久有效。
- 在 Telegram 结果之外单独保存同意来源与接收方偏好。