一句话结论：一个结构性 0% 接码的死组合 apple / 土耳其(TR)，自 7/21 起被十几个用户脚本化刷单，单周吃掉全平台 35.6% 的订单量 和 63.3% 的失败量，把表头端到端转化率从 30 天基线的 19.3% 硬拽到 ~14%。
但这是假崩盘：剔除该组合后真实转化率稳在 ~18–20%，日利润稳在 ~$84/天（24h 与 7d 均值持平）。它零完成、零营收，是噪声不是漏损 —— 真正的代价是指标污染、16,130 次白烧的供应商 API、以及 100% 失败的用户体验。
平台端到端转化率（completed / 全部下单）近期看起来从 ~19% 掉到 ~14%。但把 apple/TR 这一个组合剔除，真实转化率几乎没动：
| 时间窗 | 订单/天 | 表头转化率 | 剔除 apple/TR 后 | apple/TR 占比 |
|---|---|---|---|---|
| 前 30 天 (基线) | 1,629 | 19.3% | 19.4% | 0.7% |
| 前 7 天 | 2,745 | 13.8% | 17.7% | 22.1% |
| 近 24 小时 | 2,991 | 14.4% | 18.1% | 20.5% |
证据：apple/TR 从 30 天基线的订单占比 0.7% 暴涨到近 7 天的 22.1% —— 一场 7/21 开始的突袭。剔除它，真实转化率仅从 19.4% 微降到 ~18%（正常波动），并非崩盘。
| 日期 | 订单 | 下单用户数 | 完成 | 失败 | 取消/过期 |
|---|---|---|---|---|---|
| 7/19 | 9 | 1 | 0 | 7 | 2 |
| 7/20 | 36 | 2 | 0 | 31 | 5 |
| 7/21 ⚡ | 1,005 | 14 | 0 | 789 | 216 |
| 7/22 | 1,765 | 24 | 0 | 1,489 | 276 |
| 7/23 | 1,371 | 28 | 0 | 1,052 | 319 |
| 7/24 | 566 | 16 | 0 | 448 | 118 |
7/20→7/21 一夜之间订单量 ×28，且始终 0 完成。下单用户仅 14–28 人/天，高度集中。
| 用户 (脱敏) | 订单 | 完成 | 下单节奏 |
|---|---|---|---|
| user #1 | 488 | 0 | 8.3 单/小时 |
| user #2 | 338 | 0 | 4.3 单/小时 |
| user #4 | 229 | 0 | 28.9 单/小时（每 2 分钟一单，连刷 8h） |
头部用户单人刷 200–488 单、全部失败仍不停手 —— 典型自动化重试，非人工浏览下单。
不是「买不到号」的问题。跨供应商 fan-out 里，939 个土耳其号被成功分配（sms-bus / durianrcs / lubansms / grizzlysms 都试过），但其中 收到短信的数量 = 0。
Apple 根本不向这些聚合器的土耳其号码投递验证码（VOIP/已被过滤号段）——这是结构性不可交付，换任何供应商都救不了。每单平均触发 3.4 次跨供应商调用，累计白烧 16,130 次 API。
| 状态 · 供应商 · 路径 | 笔数 | 均价 | 均成本 |
|---|---|---|---|
| failed · sms-bus · canonical_fallback | 1,078 | $0.00 | $0.00 |
| failed · durianrcs · canonical_fallback | 1,035 | $0.00 | $0.00 |
| failed · lubansms · canonical_fallback | 927 | $0.00 | $0.00 |
| failed · grizzlysms · canonical_fallback | 727 | $0.00 | $0.00 |
失败单成本 ≈ $0（未分配即失败，先扣后退）。财务直接损失极小；真实代价是指标失真 + 供应商配额空耗 + 用户 100% 失败体验/留存流失。
GA4 会话数在爆发期完全持平（~1050/天），而订单量翻倍 —— 每会话 >3 单，人工浏览不可能。且 GA4 国家分布 top 是中国，土耳其访问量不入前 12。
结论：这批 apple/TR 是中国用户想要土耳其 App Store 验证码（土区 App Store 订阅更便宜），通过脚本直接打下单接口（绕过 GA 埋点的前端），疯狂重试一个死组合。
combo_health.enabled: false（config.production.yaml:232，注释「上线开关（默认关）」灰度开关）→ ComboHealthWorker 从不启动 → 生产 combo_health_decisions 表实测 0 行。任何死组合永远不会被自动隐藏。SMSReceived/Allocations（service.go:195），阈值 hide_threshold=1%、样本门槛 100。apple/TR 是 0% 接码 + 16k 样本，完全符合应隐藏条件 —— 只差 worker 没开。ListHidden（"Step 4" 未接线，见 route_projection.go:35-38）：隐藏只在路由层生效，不在目录可见性层。单独翻开关只会把失败模式从「4 供应商 fan-out」变成「即时空候选退款」，仍无法阻止用户继续下单该组合。ListHidden，在目录可见性层堵住隐藏组合），再灰度打开 combo_health.enabled=true，并盯隐藏名单防误伤正常组合。这才是让系统自动免疫这类死组合的根治。本轮未自主发起 PR / 未翻开关 / 未下架产品：combo_health.enabled 是团队刻意留的生产灰度开关，翻开它是影响营收与可售库存的产品决策；且单独翻开只是半解（Step 4 未接线）。按既定原则，此类路由/抑制/定价变更应由人工签发或走灰度，不做无人值守自动上线。上面 P1 一行 SQL/后台操作即可由团队立即执行。
近 24h tuna-worker 错误/警告日志 448 条，其中「严重告警：链上余额不足，可能被盗或数据库错误」重复 116 次 + 「sweep address orders skipped: balance insufficient」30 次。看形态像 TronGrid 地址池低余额的周期性重复告警（大概率已知噪声），但「可能被盗」这种措辞高频刷屏，建议花 5 分钟确认是噪声而非真事件，顺手给它加抑制/降级文案。（非本日主结论，仅提示）
方法论：所有指标取自 production 只读库 dogesms_db_production，利润按 completed 口径（先扣后退模型，避免 cancelled/expired 已退金额虚高）；转化率按下单日归集；GA4 property 512790783，时区 Asia/Singapore；代码引用为 main 分支。用户标识全部脱敏。
DogeSMS 经营情报 · 自动生成 · 数字均可用报告内 SQL 口径复跑验证