过去 24h 共 2435 单,端到端成功率 14.6%(与前 24h 的 14.3% 持平,但显著低于 30 天前 cohort 的 17.6%)。失败订单几乎全部倒在供给侧,不是用户行为:
| 状态(24h) | 订单 | 拿到号 | 没拿到号 | 解读 |
|---|---|---|---|---|
| failed | 1022 | 3 | 1019 (99.7%) | 取不到号(供给侧) |
| cancelled | 683 | 683 | 0 | 拿到号,用户取消 |
| expired | 372 | 372 | 0 | 拿到号,超时没收到码 |
| completed | 356 | 356 | 0 | 成功 |
把 1022 个「取不到号」的失败单按 service+country 拆开,apple/TR 一家独占 482 单(47%),远超第二名。
| service / country | 24h 取不到号失败单 |
|---|---|
| apple / TR | 482 |
| whatsapp / JP | 34 |
| apple / IN | 34 |
| telegram / JP | 33 |
| telegram / SG | 30 |
| 维度 | 数值 | 证据 |
|---|---|---|
| 30 天订单量 | 5742 | 占全平台 Apple 需求 83% |
| 30 天成功单 | 4(0.1%) | 基本从未交付成功 |
| 7 天供应商分配号码 | 1095 | grizzly 488 / sms-bus 382 / durian 191 / luban 34 |
| 7 天这些号收到短信 | 0 | 典型「地理拒发码」——Apple 不给这些「土耳其号」发验证码 |
| 需求爆发时点 | 7/21 起 | 此前 <100 单/天 → 之后 600–1700 单/天 |
24h 内 632 单 apple/TR 全部是 web / activation(非 API),来自 15 个用户,每人 30–132 单、集中在约 2 小时窗口内反复重试。这 15 个账户全部在 7/22–7/25 注册,累计 1700 单仅 1 单成功;期间充值 $94 真金,157 笔扣款均已 157 笔退款(计费闭环正常、无卡款)。这是一群明确刚需 Apple-ID 土耳其号的用户(土区 App Store 低价是知名玩法),发现平台「显示有货」后集中涌入,却撞上 0% 交付。
交叉验证 main 代码后定位到两层问题:
apple/TR 此刻在 sellable_catalog_offers 里状态是 sellable,grizzlysms 自报 123,003 个可用号 @ $0.71(外加另 3 家)。可用性门 availability_status 目前只会因 low_inventory(库存数为 0)触发,从不看历史接码成功率。供应商谎报海量库存 → 门通过 → 照常上架扣费。
代码里其实有一套按接码率下架的自愈机制 combo_health(repository.go:1793 已接进下单/展示查询),但:生产环境 combo_health.enabled: false(config.production.yaml:240,从未开过),且即便开启也有已知「空转」缺陷 —— 门槛 min_sample_size=100 按单个(供应商,服务,国家)三元组统计,apple/TR 这种分散在 6 家供应商上的长尾组合永远凑不够样本(见 changes/2026-06-30-combo-health-inert-observability.md)。
apple/TR 订单走 canonical_fallback → cross_supplier_fallback,一单 fan-out 到 6 家供应商。其中 5sim 和 majorphones 结构上根本不支持土耳其(majorphones 编译期静态表只有 US/GB/FR/DE/IN),每次必返 INVALID_COUNTRY:
| 供应商(apple/TR 24h) | 调用次数 | 分配成功 | 错误码 |
|---|---|---|---|
| durianrcs.com | 631 | 34 | NO_NUMBERS / SERVER_ERROR |
| 5sim.net | 521 | 0 | INVALID_COUNTRY |
| majorphones.com | 503 | 0 | INVALID_COUNTRY |
| lubansms.com | 439 | 3 | NO_NUMBERS |
| sms-bus.com | 359 | 71 | NO_NUMBERS |
| grizzlysms.com | 88 | 41 | NO_NUMBERS |
全站 24h 共 1728 次 INVALID_COUNTRY 无效调用(majorphones 868 + 5sim 726 + luban 130),apple/TR 一家贡献约 59%。这些是纯浪费的候选迭代 + 审计写入 + 串行超时。
把「7 天分配 ≥30 个号、但 0 个收到短信」的组合全捞出来,共 8 个,全部显示为 sellable、全部在扣款→退款:
| 组合 | 7天分配号数 | 收到短信 | 涉及用户 |
|---|---|---|---|
| apple / TR | 1095 | 0 | 59 |
| telegram / RU | 131 | 0 | 61 |
| facebook / PL | 86 | 0 | 5 |
| whatsapp / JP | 82 | 0 | 13 |
| telegram / SG | 78 | 0 | 79 |
| telegram / NI | 63 | 0 | 46 |
| whatsapp / ID | 53 | 0 | 21 |
| openai / SG | 41 | 0 | 19 |
需说明:核心营收没有因此崩盘 —— 近两周实收利润稳定在 $90–114/天,毛利率 51–55%;GA4 流量平稳(~1000 sessions/天,apple/TR 不是流量激增,而是存量用户扎堆)。所以这是一个「未变现的需求 + 悄悄流失的信任」问题,不是「收入正在下跌」的问题。
| 日期 | 成功单 | 毛收 $ | 利润 $ | 毛利率 |
|---|---|---|---|---|
| 07-21 | 496 | 212.99 | 113.98 | 53.5% |
| 07-22 | 440 | 177.60 | 97.80 | 55.1% |
| 07-23 | 431 | 183.89 | 94.73 | 51.5% |
| 07-24 | 428 | 171.56 | 91.49 | 53.3% |
| 07-25* | 325 | 135.17 | 74.78 | 55.3% |
* 07-25 为部分日(截至 20:07 UTC)。
service_country_fulfillment_controls 表(mode='suspend_sales',已被展示 + 下单双路径消费,生产已有 156 条类似记录)。运营对 (apple,TR) 等组合下一条 suspend_sales,即刻从用户侧消失、停止扣款。这是 prod 写操作 + 营收决策,留给人类拍板(Claude 只读、不自动写 prod)。
combo_health.enabled: true,并按 changes/2026-06-30 已认可的方向修「空转」:min_sample_size 100→20-30、统计粒度从(供应商,服务,国家)收粗到(服务,国家)跨供应商池化。这样能自动收敛未来所有「谎报库存但 0 交付」的组合。涉及营收,建议人工 + 灰度。
CanonicalCountrySupport,让外部聚合器在派单前声明「结构上是否支持某国家」,routing 层据此跳过必然失败的候选(如 majorphones 对 TR)。行为中性:不支持的国家本就 100% 失败,只是提前跳过省掉无效 attempt + 审计写入 + 串行超时(每单少跑 1–2 家、降低取号延迟)。数据已现成(majorphones 编译期静态表),复用既有 PoolSupplier.SupportsCountry 同款模式。已实现 majorphones,5sim(运行时缓存,需 fail-open)留作后续。已配单元测试,本地全绿。