过去 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）留作后续。已配单元测试，本地全绿。