NexCheck-筛号平台
你刚跑完一轮号码检测，结果表已经写好，但心里在打鼓：这些结论能信多久？明天还能直接拿来发消息吗？先说结论：批量筛号结果没有平台官方定义的“有效期天数”，结果是否失效要看三个可观察信号——探测侧是否踩了限流、名单侧是否发生变更、触达侧是否出现背离。
行业内多数筛号 API（如 CheckNumber.AI 等）默认提供 force_check 缓存开关，意味着读缓存是工程默认，问题只在于什么时候该强制刷新。下面把三档信号拆开讲。
先给结论：批量筛号结果失效看三个信号，不看固定天数
不要在日历上给结果定一个“30天过期”，而是监控以下三类信号，一旦出现就该触发复检。
| 信号侧 | 可观察指标 | 触发复检条件 | 优先级 |
|---|---|---|---|
| 探测侧 | 429 响应、retry_after 字段、连续超时 | 检测当时踩过频控，结果混入异常 | 高 |
| 名单侧 | 新增导入、字段改写、归一化版本变化 | 号码键值变化，旧结论不可比 | 中 |
| 触达侧 | 发送失败率背离检测结论 | 失败集中于某批次或某时间窗 | 高 |
这三类信号覆盖了结果失效的绝大多数场景，比固定天数更可靠。
信号一（探测侧）：限流窗口内拿到的结论不能直接进主表
为什么要重视探测侧？因为检测结果是在限流压力下产生的。LINE Messaging API 按端点设置每秒速率限制，超限直接返回 429 错误（LINE 官方 2026 年 5 月更新规范），需要客户端设计速率控制与指数退避。Telegram 官方要求 contacts.resolvePhone 至少 3 秒一次防抖，否则可能触发 flood wait。如果在限流窗口内强行探测，拿到的结论可信度低，尤其是返回了 429 或 retry_after 的批次。
做法：把 429、retry_after 期间的返回值标记为“异常未知”，而不是阴性结论，单独排队复检。
信号二（名单侧）：新增导入、号码改写与重新归一化会让旧结论失去可比性
名单本身变了，旧结论就失效。常见三种情况：
- 新批次导入，和旧名单混合；
- CRM 中号码字段被人工改写（比如补了国家码）；
- E.164 归一化规则调整，导致同一号码键值变化。
实操：以归一化后的号码为缓存主键，记录归一化版本号，键值变更即视为新号码强制重探。若你用的是平台提供的 批量号码检测API，可在提交时带上版本号，便于后期按版本筛选。
信号三（触达侧）：发信失败率与检测结论背离时，先复检哪一部分
“检测显示可用但发送还是失败”的排查顺序很重要。先区分四个概念：格式有效、平台注册、账号活跃、可触达，它们是层层递进的。例如 Telegram 的 PHONE_NOT_OCCUPIED 既可能是未注册，也可能是用户隐私设置拦截，并不等于“没账号”。
排查步骤：
- 看失败集中在哪个平台、哪个批次；
- 若失败集中在某个时间窗，多半是当时探测遭遇限流，优先复检该窗口子集；
- 检查是否因发送频率过高触发平台风控，而非号码本身问题。
可参考 多平台号码检测 的思路，跨平台对比状态矩阵。
为什么“未知”档必须单独排期复检，“已注册”不必每轮重刷
把检测结果建模为三档，而非简单的布尔值：
| 档位 | 含义 | 复检优先级 |
|---|---|---|
| 已注册 | 明确探测到账号存在 | 低，变化慢可延长复用 |
| 未命中 | 未注册或隐私限制，如 PHONE_NOT_OCCUPIED | 中，按用途决定 |
| 异常未知 | 探测时遇限流或超时，结果不明 | 高，信息量最低最值得重跑 |
若把三档压回布尔值，会丢失信息，导致假阴性误判。所以结果表要保留状态档位列。
缓存开关怎么用：什么时候读缓存、什么时候 force_check
force_check 参数是多数筛号 API 提供的缓存开关，默认读缓存以省配额、降低限流风险；遇到上述三类信号时才强制重新探测。
按名单用途分档的复检节奏（经验值，非平台规定）：
| 名单类型 | 建议节奏 |
|---|---|
| 高频触达名单（近7天活跃） | 每2-3天抽查子集 |
| 季度沉睡名单 | 每季度全量复检 |
| 一次性活动名单 | 活动前复检一次 |
只重跑子集：批次号、检测时间戳与增量任务队列
工程实现上，结果表应保留批次号、归一化版本、检测时间戳、状态档位与错误码列。用查询条件筛出待复检子集，交给异步队列分批提交，用回调回写状态，避免整批重刷。
具体字段：
| 字段 | 作用 |
|---|---|
| batch_id | 区分来源批次 |
| normalized_version | 归一化版本 |
| checked_at | 检测时间戳 |
| status_tier | 已注册/未命中/异常未知 |
| error_code | 429、timeout 等 |
例如：先筛选 status_tier='异常未知' AND error_code='429' 的子集，复检后回写。
这里可以接上 NexCheck：它提供网页端批量筛选与 RESTful API 的批量提交、实时查询与 webhook 回调，可把复检做成按批次号与检测时间戳驱动的增量任务，回调回写状态列，而不是每轮全量重刷；同时支持 WhatsApp号码批量检测、社交账号注册检测等多平台统一提交，减少为各平台分别维护缓存与重试策略的成本。
复检成本对账：重复提交、并发上限与配额怎么估
复检不是免费的，要估算成本：
- 按档位占比推算每轮实际重跑量，例如异常未知占 5%，只重跑这部分；
- 把限流退避导致的重试计入配额消耗，因为每次重试都可能消耗配额；
- 设置止损规则：单号码单周期最多重探 2 次，防止死循环。
这样既能控制成本，又不会浪费资源。
常见问题
筛号结果能保存多久还有效？
平台官方没有定义“有效期天数”，不能给固定数字。结果是否有效看三个信号：探测时是否踩限流、名单是否变更、触达失败率是否异常。若三方面都正常，可继续复用缓存；若出现异常，即使刚跑完也得复检。
批量筛号多久重跑一次比较合适？
没有统一间隔，按名单用途调整。高频触达名单建议每 2-3 天抽查子集；季度沉睡名单每季度全量复检；一次性活动名单活动前复检一次。这是运营经验值，不是官方规定。
force_check 参数是什么意思？
force_check 是筛号 API 的缓存开关，默认读缓存以节省配额，设置为 true 时强制绕过缓存重新探测。适用场景：号码疑似变更、上次探测踩限流、或触达失败但检测显示正常时，强制刷新单条或子集。
上次筛过的号码还需要再筛一遍吗？
不一定。如果名单未变、上次未踩限流、且触达正常，可以直接读缓存；若出现新增导入、号码改写或失败率上升，则需对受影响子集重新探测。优先重跑“异常未知”档，不必全量重刷。
PHONE_NOT_OCCUPIED 是没注册还是被隐私拦截？
两者皆有可能。Telegram 官方文档（2026 年 5 月更新）说明，该返回码既可能是号码未注册，也可能是用户设置了禁止通过手机号查找。不能据此判断“没账号”，应标记为“未命中”档，结合其他渠道信息综合判断。
检测显示可用但发送还是失败怎么排查？
先区分格式有效、平台注册、账号活跃、可触达四层，再看失败是否集中于某批次或时间窗。若集中在某一时段，多半是当时探测遇限流，优先复检该子集；若仅单向发送失败，可能是平台风控，需检查发送频率。
评论(0)