沉默的漏斗：四分之一的下单，打在我们根本供不出货的组合上

01为什么这是今天最该看的一条

近 24h 一个反常信号：订单量涨了（1185 → 1508，+27%），但完成率反而从 25.2% 掉到 18.8%，失败订单几乎翻倍（150 → 389）。表面像是「量大了质量下降」，但拆开后是另一个故事。

先排除两个常见误判：

• 不是收码失败（接码率）问题——失败订单里 99.5%（387/389）是"根本没分配到号码"，只有 2 笔是拿到号但没收到码。这是取号/供给层的问题，不是短信送达问题。
• 不是流量异常——GA4 显示 sessions 稳定在 ~1,800–2,100/天（07-03: 1808，07-02: 2115，07-01: 1982），没有流量突增。不是"更多人来了"，而是"来的人撞墙了"。

真正的根因：这些「没取到号」的失败里，近 69% 落在 7 天成功率 < 2% 的组合上，加上 2–10% 的"弱组合"共占 88%——也就是说，绝大多数失败不是"好产品临时缺货"，而是用户被允许下单（并反复重试）我们结构上就供不出的组合。真正健康产品的临时缺货只占 1.8%。

02这是慢性病，不是今天的意外

把窗口拉到 30 天，死路组合的下单占比每一天都在 16%–36% 之间——从来没消失过。近几天（06-30、07-01）冲到 36%。这不是一次抖动，而是一个长期存在、约占 1/4 订单量的结构性漏损，只是因为不扣费而从没进过任何看板。

（表为节选；30 天内每天死路占比均在 16–36% 区间。可见失败率与死路占比高度同步——死路组合就是失败率的主要推手。）

03钱在哪、痛在哪：两类死路，两种药

把 7 天的死路下单按「有多少不同用户在要」拆开，得到两个截然不同的问题：

A. 11 个「广泛需求」死路组合 = 桌上的钱

这些是很多不同用户反复在要、我们却几乎永远给不出的组合。openai/CA 是最扎眼的：136 笔下单、83 个不同用户，只成功 2 笔。这是明确的、可变现的需求，我们要么把货组出来，要么至少别再让它出现在选项里误导用户。

🀄 中文系服务（redbook-xiaohongshu/CN 217 笔、telegram/CN、tiktok/CN、alipay/CN、weibo/CN）成功率清一色 0%——与既往观察一致：中文流量把想要亚洲/中国号码的用户引进来，但我们没有对应货源。要么停止对这些用户展示，要么补货。

B. 475 个长尾组合 + 少数用户重试刷单

长尾里大量是"某几个用户各试几次、几乎全灭"的小众组合。极端个案：一个用户 3 天内为 wolt/RS 下了 62 单、45 单失败；另一个用户为 telegram/KZ 单独下了 44 单失败。系统目前只有"最多 2 个并发订单"的限制（MaxConcurrentOrders=2），没有任何"同一死路组合的重试冷却"——用户可以每几秒就把同一个必败组合再点一遍，每次都触发一整轮供应商 fallback 空烧。

04根因已在代码里定位（交叉验证）

后端代码确认：下单链路上完全没有"可用性 / 库存"检查。

• 下单创建 service/order/service.go:391-530 只校验 catalog 是否有可售 offer + 价格，从不调用 GetAvailableCount()。
• GetAvailableCount() 在 supplier 接口里存在但从未在下单时被调用（supplier/interface.go:17）。
• comboHealthRepo（组合健康度）只在fallback 候选过滤时用（service/supplier/service.go:418），下单入口不查它——所以任何有 catalog offer 的组合都能下单，无视近期是否 100% NO_NUMBERS。
• 选品/路由错配佐证：5sim.net 对 redbook/CN 返 INVALID_COUNTRY 216 次、对 telegram/CN 88 次——我们把订单路由给了根本不支持该地区的供应商。这是纯配置/路由问题，不是缺货。

好消息：修复所需的两块能力（GetAvailableCount + comboHealthRepo）都已经写好了，只是没接到下单入口。这让 P1 修复的工程量和风险都很低。

05业务体检：收入稳，这是"隐形效率+体验"漏损

要强调的是——这不是收入起火。当前各项收入指标都在正常区间：

正因为收入看板一切正常，这个问题才更值得点出来：你的看板看起来没事，但每 4 个尝试下单的用户里就有 1 个撞上一堵你看不见的墙——这是增长天花板和留存的慢性失血，不是当期收入的波动。

06建议动作（按优先级）