过去 24h 订单量其实上升了 9%（1645 vs 1508），但端到端完成率却逆势下滑到 16.1%（30d 24.1% → 7d 20.4% → 昨日 18.8% → 今日 16.1%，四级台阶式下跌）。深挖后发现：这不是供应商单点故障，而是需求 mix 正持续涌向一批我们几乎没有货源的 service+country 组合，这些订单以 96.8% 的概率必败，白白拖低全站转化、并烧掉近 1/4 的供应商 API 调用。
把过去 7 天 supplier_execution_attempts 按 service+country 聚合，筛出「调用量 ≥ 50 且取号率 ≤ 10%」的组合，得到 24 个死路组合，平均取号率仅 2.4%。它们在过去 24h：
| Service | 国家 | 7d 调用 | 取号率 | 货源现状 |
|---|---|---|---|---|
| telegram | KZ 哈萨克斯坦 | 782 | 9.3% | 近乎无货 |
| redbook-xiaohongshu 小红书 | CN 中国 | 645 | 0.0% | 零货源 |
| telegram | OM 阿曼 | 365 | 0.0% | 零货源 |
| IN 印度 | 330 | 6.1% | 近乎无货 | |
| telegram | TW 台湾 | 305 | 1.0% | 零货源 |
| telegram | CN 中国 | 272 | 0.0% | 零货源 |
| telegram | KR 韩国 | 209 | 1.0% | 零货源 |
| telegram | CH 瑞士 | 177 | 0.0% | 零货源 |
| telegram | SG 新加坡 | 111 | 9.9% | 近乎无货 |
| SY 叙利亚 | 99 | 0.0% | 零货源 |
财务侧已确认无资金损失：死路订单走反转扣款流，失败即全额退款（过去 24h debit $3.45 = refund $3.45 完全对冲）。损害集中在用户体验、转化率、以及浪费的供应商调用配额三处。
死路组合高度集中在 中国 / 港澳台 / 东南亚 / 独联体 号码。GA4 过去 2 天数据给出了需求侧的直接解释：
| GA4 用户地区 (2d) | 活跃用户 | 信号 |
|---|---|---|
| 🇨🇳 中国 | 1127 | 第一大来源 |
| 🇺🇸 美国 | 601 | 货源充足 |
| 🇯🇵 日本 | 279 | 货源紧张 |
| 🇭🇰 香港 | 192 | 近乎无货 |
| 🇸🇬 新加坡 | 182 | 近乎无货 |
| 🇹🇼 台湾 | 68 | 零货源 |
头号落地页是中文支柱博文 /zh-CN/blog/sms-verification-platforms-2026-guide（621 sessions，仅次于首页），流量来源里 cn.bing.com(339)、v2ex.com、iplaysoft.com、导航站 axutongxue 等清一色华语渠道。
系统里唯一能自动屏蔽劣质组合的机制是 combo_health 自愈 worker。经 main 分支代码核对，它存在两个叠加缺口，导致死路组合永远可下单：
backend/config/config.production.yaml 中 combo_health.enabled: false（注释写着「上线开关（默认关）」）。生产库 combo_health_decisions 表至今 0 行、从未做过任何一次自动隐藏决策——铁证。
该门的判定口径是 接码率 decodeRate = SMSReceived / Allocations（见 combohealth/service.go:191），隐藏阈值 HideThreshold = 0.01（1%），且要求 24h 样本 MinSampleSize ≥ 100。表结构也只有 decode_rate_24h / decode_rate_7d 两列，根本没有取号率维度。
NO_NUMBERS），Allocations ≈ 0，于是 decodeRate = 0/0 无法计算、门永远无法对它们触发。— 也就是说，即便运营明天把开关打开，telegram+CH、redbook+CN 这类 0% 取号的组合依然会漏过去。
供应商上报的 availableCount > 0 是「幽灵可用」：报了库存但实际取号返 NO_NUMBERS。前端、catalog、下单三层全程只信任这个幽灵信号，没有任何一层参考历史取号成功率。
核心修复会改变「哪些组合可下单」这一产品行为，且阈值需要经验标定——按既往规则（改动组合可见性/推荐权重需人评 + 灰度，不做无人值守上线），本次不自动提交并合并 PR，而是给出精确到文件/行号的方案交团队拍板。
service_country_fulfillment_controls（suspend_sales）或 Admin 手动下架。可立刻回收 ~24% 的浪费调用、抬高全站完成率约 2.4pt。combohealth/service.go 的评估逻辑里，除 decodeRate 外新增 allocRate = Allocations / Attempts 门：当 attempts ≥ N 且 allocRate ≤ 阈值 时判 hide，unhide 沿用现有双窗口（24h+7d 同时回升）逻辑；combo_health_decisions 表加 alloc_rate_24h / alloc_rate_7d 列。这是唯一能覆盖「取号即失败」死路的修复。enabled: false。补完取号率维度后，先小样本/影子模式观察它会隐藏哪些组合，确认无误伤（如临时低接码率的热门服务）再全量。