过去 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。补完取号率维度后,先小样本/影子模式观察它会隐藏哪些组合,确认无误伤(如临时低接码率的热门服务)再全量。