你写了个脚本，从页面里解析出一批视频线路，然后按"第一个能用的就选它"的策略挑一条。逻辑很直白：从前往后找，谁先"可用"就用谁。跑起来才发现，脚本选中的那条线路，十次里有八次是打不开的。
现象
- 脚本从页面解析出一批候选线路（若干条，数量不等）；
- 按"第一个可用就赢"的顺序挑，选出的那条经常打不开——播放失败、超时、或者直接报错；
- 手动把它换到第二条、第三条，往往就能播了；
- 而且同一个页面不同时间解析，选出来的还是那条"死线路"，问题稳定复现。
根因
根因是："可用"这个判断本身太弱了，而"线路大多是死的"这个分布又被忽略了。
这类站点的线路列表有个普遍特征：大部分候选是失效的。 时间久了链接过期、资源被撤、地址变更，列表里真正能播的可能只有少数几条。也就是说，"死"是常态，"活"是少数。
在这个分布下，"第一个能用的就赢"里的"能用"，如果只验证到"索引文件存在、能取到内容"这一层，就会出问题——它验证的是"这个地址有东西"，而不是"这个东西真的能播"。很多时候一个地址能返回一个小文件（比如一个错误页、一个空列表、一个旧的占位内容），表面上"拿到了"，实际根本不能播放。
于是就出现了这个结果：脚本从前往后扫，第一条"看起来能拿到内容"的死线路就被选中了，然后停在那里——后面明明有能播的线路，也永远不会被考虑。这不是随机的，所以它稳定复现：每次都是同一条。
解决
改成先探测、再选择，并且维护一个"坏线路"黑名单：
1. 解析出所有候选线路（不要中途就 return）
2. 逐条探测真实可用性
for line in candidates:
if line in bad_list: # 命中黑名单，直接跳过
continue
ok = probe(line) # 见下方"探测做什么"
if ok:
usable.append(line)
else:
bad_list.append(line) # 记入黑名单，下次不再浪费时间去试
3. 在"真正可用"的集合里选
- 按优先级/清晰度/历史成功率排序
- 或对前几条做一次更严格的实测，选最快的
4. 播放失败时回退
- 播放过程中失败 → 把当前线路记入黑名单 → 自动换下一条
其中探测（probe）才是关键，它必须比"能取到内容"更严一些。可用的手段按强度递增：
- 看响应的内容类型和长度：返回的是一个正常的索引/清单文件，还是一个错误页？长度合理吗？
- 取一小段真实媒体数据：从目标里拉第一个分片的一小部分，确认它确实是媒体数据（看魔数、看长度），而不是一段文本错误信息。
- 对分片做一次解码试探：能解出帧，才是真的能播。这一步成本最高，但对"必须一次选对"的场景值得。
黑名单要持久化。 把探测失败的线路存下来（带上时间戳，因为死线路偶尔会复活），下次选源时优先跳过。这能把"每次都要重新试一遍同样的死线路"的开销彻底省掉。
延伸与预防
这条坑的通用教训是：别把"拿到了地址"当成"这个地址能用"。
"可用性"是有层次的，混为一谈就会选错：
| 层次 | 验证了什么 | 典型失误 |
|---|---|---|
| 地址存在 | 请求能发出、有响应 | 把 404 页面/错误页当成功 |
| 内容可获取 | 能取到一份内容 | 取到的是错误信息、空列表 |
| 内容正确 | 取到的东西确实是想要的类型 | 内容类型对但数据损坏 |
| 功能可用 | 实际使用（播放/解析/调用）成功 | 这一步没过，前面对了也没用 |
很多"看起来选对了却不能用"的问题，都出在只验证了前两层、就当成最后一层。判别方法很简单：问一句"我验证的是'能拿到'，还是'能用'？"前者是必要条件，不是充分条件。
另一个可迁移的点是**"取第一个成功的就停"这个模式本身**。它在两种情况下是安全的：候选里绝大多数是好用的，或者"错误"会明确报出来（失败会抛异常）。而一旦"坏候选是常态"且"坏候选不报错、只是悄悄返回无用的东西"，这个策略就必然失效——因为"第一个成功的"很可能是"第一个假装成功的"。这时必须换成"全部探测完再选，并记住哪些是坏的"。
最后，探测是有成本的。别对几百条候选都做最重的探测——先做一轮便宜的粗筛（内容类型、长度），只对通过粗筛的少数几条做重量级验证，再从中选最优。探测的成本和它挡下的错误，要有取舍。