一个冷门资源下载得很慢，速度长期卡在一个很低的数值。你的第一反应是"是不是没开多线程下载"，于是在客户端的设置里翻来翻去，找那个根本不存在的开关。这属于典型的一开始就找错了杠杆。
现象
- 下载速度上不去，长时间维持在很低的水平；
- 翻遍客户端设置，找不到任何"多线程"相关的选项；
- 你可能会退一步去看"来源质量评分"，专门挑评分最高的那个候选——结果它常常是最慢的那个；
- 换了评分更高的来源，速度依然没改善。
根因
有两层误解叠在一起。
第一层：BT 协议本身就是并行的，没有"开多线程"这回事。
在这类协议里，一个文件被切成很多个小分片（piece），客户端会同时向多个对端并行请求不同的分片，再把它们拼起来。也就是说，"从多个来源并行拉取"是协议内建的行为，不是要靠某个开关打开的。你去找的那个开关，在概念上就不存在。
那么真正的瓶颈在哪？在于**"你能连上多少个对端"以及"这些对端手里有没有你要的数据"**。速度 ≈ 对端数量 × 每个对端的有效带宽。所以真正有效的杠杆是两件事：连更多的对端、找到更多的对端。
第二层：画质/质量评分完全预测不了来源的健康度。
很多索引站会给每个候选打一个"质量分"，通常基于分辨率、码率、编码类型这类静态属性。它是"这个文件本身长什么样"的评分，不是"这个种子还有没有人在做种、做种的人上传带宽多大"的评分。一个码率很高的候选，如果只剩一两个做种者在慢速上传，实际速度会惨不忍睹；反过来，一个码率平平但做种者众多的候选可能快得多。所以照着评分挑最高分，很可能一直在挑最慢的那个。
解决
对单个资源，最有效的办法是赛马：把能找到的所有候选全部投上，等一到两分钟，观察各自的实际速度，留下最快的，把其余的任务删掉（注意只删任务、别连带删文件）。
1. 搜同一部影片，把前 N 个候选全部加入任务
2. 等 1~2 分钟，让每条都跑出真实速度
3. 按当前下载速度排序
4. 保留最快的 1 条继续跑，其余任务删除（不删文件）
5. 每隔一段时间回看一次，速度掉下来了再补投新的候选
对"对端数量"这个杠杆，可以做几件实事：
- 提高客户端的最大连接数上限；
- 保证 DHT、PEX（对端交换）等功能开启，它们能帮你不断发现新对端；
- 给冷门种子补上公共 tracker（这部分见"给种子设了 tracker 却只有一种添加方式生效"一条的时机问题）。
最后要接受一个现实：冷门资源挂机一晚是常态。 如果数据结构里做种者本来就少，那再优化客户端参数也快不起来，只能靠时间累积——或者干脆放弃 P2P，改走 HTTP 直链多线程方案（如果有）。
延伸与预防
这条坑的通用教训是：找错了瓶颈，再多的开关也没用。
在动任何参数之前，先花一分钟明确"当前真正的瓶颈是哪一环"。常见的误区模式有几种：
- 以为瓶颈在并发，于是找多线程开关，而真正的瓶颈在数据来源本身（P2P 的对端数量、API 的限流、数据库的锁）；
- 以为瓶颈在自己这边，拼命调本地参数，而真正卡住的是远端的响应速度；
- 用一个错误的代理指标选优——像这里的"质量分"，它衡量的是 A 属性，你却在用它决策 B 目标。凡是遇到"我按这个指标挑了最好的，实际却最差"，第一反应应该是"这个指标真的是我想优化的东西吗"。
一个可靠的做法：先用最小的成本测出每一环的真实上限。 比如先单独测一下"最快能连上几个对端"，就知道瓶颈在不在对端侧；先拿一条已知的好资源跑一遍，就能区分"是这条资源的问题"还是"是我整体配置的问题"。先测量、再优化，比先翻设置面板省时间得多。