BitComet 长效种子深拆：为什么老资源 99% 卡住能被它救回来
BitComet 是什么
BitComet，中文名叫比特彗星，是一款开源免费的资源下载工具，BT 协议客户端里的老牌选手。手机版提供 torrent 种子文件和磁力链接两种 BT 下载方式，同时还支持 HTTP/FTP 多线程多镜像下载——一个 APP 覆盖两种主流下载场景。
它的核心竞争力不在界面花哨，而在几个业内首创的技术点：长效种子、HTTP 镜像自动搜索、以及 BT + HTTP P2P 的混合加速。很多用过 BitComet下载 的用户可能只是觉得"这个下载器好像比其他的能下到更多老资源"，但背后是一套对 BT 协议固有缺陷的系统性补完。
安装
BitComet 手机版目前是 Android APK 形态，安装包约 26.81MB。安装路径和大多数 Android APP 一样，但有几个 BT 下载特有的前置条件值得注意。
首先，下载目录的存储权限必须给到。Android 11 及以上版本会弹出分区存储的权限请求，选择"允许所有文件访问"才能让 BitComet 在非默认目录下读写大文件。如果只给了"仅允许访问媒体文件"，BT 任务下载到一半就会因为写入失败而暂停。
其次，首次启动建议立即配置"自启动权限"和"后台无限制"。这两个设置直接影响长效种子功能能不能发挥作用——如果 BitComet 被系统杀掉后台，它既不能作为长效种子为其他用户提供数据，也无法在你自己下载的任务断种时保持监听状态。小米、OPPO、vivo 等国内厂商的系统优化比较激进，这两个权限默认都是关的，需要手动在系统设置里打开。
最后，内网用户如果想让自己作为长效种子节点被其他 BitComet 用户连到，还需要在路由器上做端口映射（把 BitComet 使用的 TCP/UDP 端口转发到手机的局域网 IP），或者确保手机和电脑在同一个 Wi-Fi 下时路由器启用了 UPnP。
长效种子：BT 协议死局的解法
我想从一个所有人都遇到过的场景切入：你在网上翻到一部三五年前的纪录片，找到磁链丢进下载器，进度条好不容易爬到 99%，然后……就不动了。Tracker 服务器显示种子数为 0，DHT 也搜不到任何对等节点。传统 BT 协议下，这就是死局——没有拥有完整文件的节点给你补最后那几个分片，任务永远卡住。
BitComet 的长效种子（Long-Term Seeding）就是冲着这个死局来的。官方声称它是业内首创，但真正有意思的是它的设计思路——不是去改 BT 协议本身（那不可能，协议是标准），而是在 BT 协议外面叠了两层补充数据源，形成一个三路并行的下载架构。
三层数据源架构
当一个 BT 任务开始后，BitComet 并行尝试三条路：
第一条是传统 BT 源：Tracker 返回的种子和对等节点，加上 DHT 网络发现的节点。这条路和任何 BT 客户端都一样，是基础盘。如果种子充足、Tracker 活跃，任务靠这一条路就能跑完。
第二条是长效种子池：BitComet 自己的云服务节点里登记的、已经完成该任务的 BitComet 用户。这些用户的客户端虽然可能早就关闭了正常的做种功能，但 BitComet 进程还在后台跑着，或者至少曾经短暂在线被登记过。当新的下载者进来时，BitComet 会通过云服务通知这些节点"有人需要 X 资源的 Y 分片"，它们就把缓存中的数据发过去。
第三条是HTTP 镜像搜索：BitComet 用 BT 任务的文件名和资源标题作为关键词，调用搜索引擎去找同一个资源的 HTTP/FTP 下载链接。找到后把它作为额外数据源接入——这时候 BT 任务就变成了一个混合下载任务，BT 分片和 HTTP 分片同时写入同一个文件。
后两条路就是长效种子的核心。一个任务如果第一条路跑得通，后两条可能根本不会被激活。但一旦传统源断了、种子数降到 0，长效种子就自动接管。
取舍：它为什么在冷门资源上有优势
这套架构的设计取舍很清晰——放弃对私有种子的支持，换取对公共资源断种场景的覆盖。
私有种子（Private Tracker）是 BT 社区里比较封闭的场景——Tracker 只允许白名单内的对等者连接，不接受外部节点。长效种子池和 HTTP 镜像恰恰都不在 Tracker 白名单里，所以私有种子任务中长效种子功能会被自动禁用，无法绕过。这不是 Bug，是设计决策：私有种子社区对做种率、分享率有严格要求，BitComet 选择不介入这个场景，把精力集中在公共资源上。
第二个取舍是消耗上行带宽换取下载成功率。作为长效种子为别人提供数据时，你的 BitComet 客户端会持续占用上行带宽。这在宽带套餐里特别明显——大多数家庭宽带上下行不对称（比如 100M 下行 / 20M 上行），上行被吃满后所有上网活动都会卡顿。BitComet 提供了独立的长效种子上传限速（和 BT 做种限速分开），建议设一个合理的上限（比如全局上传限速的 30%），避免影响正常使用。
第三个取舍是隐私换便利。参与长效种子池意味着你的 BitComet 客户端会定期和 BitComet 的云服务节点通信，告知"我拥有哪些资源"。对大多数用户来说这不是问题，但如果对隐私极度敏感，可以在选项里把长效种子整个关掉——关掉后 BitComet 就完全退出池子，既不请求别人的长效种子，也不为别人提供。
判断：什么时候它真的有用
长效种子不是万能的。如果一个资源本身就热门、Tracker 也活着，BitComet 和其他 BT 客户端的下载表现差别不大。它的价值恰恰体现在两个极端场景：
老资源断种：发布了几个月到一两年的资源，原始种子大概率已经离线。但可能有其他 BitComet 用户下载过、正在作为长效种子做种。这时候你能不能拿到那最后 1% 的分片，取决于有没有同资源的 BitComet 用户在池子里。
Tracker 挂了或私有种子失效：长效种子配合 DHT 网络，有可能绕过失效的 Tracker 继续下载。但这条只对公共资源有效，私有种子还是不行。
反过来说，如果一个资源全是 qBittorrent 用户在下载，BitComet 的长效种子池里就找不到任何节点——因为长效种子池只登记 BitComet 用户。HTTP 镜像搜索不依赖客户端类型，但冷门资源大概率也搜不到镜像。
协议选择的细节
长效种子底层用什么传输协议，在高级设置里可以调。默认是只用 TCP，兼容性最好；改成只用 UDP 可能速度更快，但某些校园网或企业网会屏蔽 UDP 包；选 TCP + UDP 同时用理论上效果最好，但也最占连接资源。对普通用户来说保持默认的 TCP 就行，除非你明确知道自己的网络环境对 UDP 友好。
多镜像多线程：HTTP 下载的加速逻辑
BT 之外，BitComet 对 HTTP/FTP 下载也做了专门优化，这一块和长效种子是两条独立的加速通道。
核心思路是多镜像 + 多线程叠加。HTTP 下载的瓶颈通常在服务器端——热门站点被几万用户同时访问，人均分到的带宽就很有限。多线程把文件切成 N 段从同一个服务器拉，但服务器总带宽有限，开太多线程反而会被限速。多镜像则是找到多个内容相同的下载地址，把不同的下载段分配到不同服务器上，速度理论上可以线性叠加。
在 BitComet官网 的技术文档里，BitComet 把两个结合起来，HTTP/FTP 下载默认开 10 段并发，同时自动搜索最多 10 个镜像服务器。搜索过程是全自动的——拿到 URL 后，BitComet 把文件名和文件大小作为关键词调搜索引擎搜，过滤掉广告页和 404，对候选 URL 发 HEAD 请求验证文件大小偏差不超过 5%，合格的加入下载通道。下载过程中还会每隔 10 分钟重新搜一次，可能发现新的更优质的镜像。
这层加速和 BT P2P 加速还能叠加——BitComet 会同时尝试从其他正在下载同一文件的 BitComet 用户那里拉数据。理想条件下（热门资源 + 大量镜像 + 大量 P2P 用户），速度可以比单源下载快 3 到 5 倍。当然，冷门资源可能一层都没命中，但对热门开源软件（比如 Ubuntu ISO）效果是实实在在的。
三层限速体系：为什么下载会把上网卡死
很多用户的直观体验是：BitComet 一开，浏览器就打不开、视频网站转圈、家里其他人的手机也上不了网。本质是下载器跑满了带宽，尤其是上行——大多数宽带套餐上下行不对称，BT 下载完自动做种、或者 HTTP P2P 加速的上传，很容易把本来就不大的上行带宽吃满。上行一满，ACK 包、DNS 查询、SSL 握手这些小包都发不出去，所有上网活动都会卡顿。
BitComet 的解法是一套三层限速体系，从全局到单任务再到长效种子专用，每一层都可以独立设置。多个限速同时存在时取最严格的那个。
对普通家庭用户来说，推荐的初始配置很简单：全局限速里，下行带宽留 20% 给其他应用，上行带宽留 50%（因为上行更容易被吃满）。长效种子上传单独设一个上限（比如 BT 上传限速的 30%），避免后台默默跑的时候把上行全部用光。工具栏右侧的实时速度条右键还能一键切换预设档位，日常调整不需要每次打开选项对话框。
总结：它解决了什么、没解决什么
BitComet 的核心设计哲学可以概括成一句话：在标准协议之上叠补充层，而不是去改协议本身。长效种子是对 BT 协议断种死局的补完，多镜像搜索是对 HTTP 单源瓶颈的补完，三层限速是对 P2P 应用带宽抢占的补完。每一层都没有重新发明轮子，而是在别人的标准之上做增量。
这种设计的优点是兼容性好——不需要其他人也用 BitComet 才能让长效种子生效（HTTP 镜像那一条完全不依赖客户端类型），也不需要 Tracker 服务器配合。缺点是功能叠加带来了复杂度——新手打开选项对话框会被几十个配置项吓到，而且某些高级功能（比如长效种子协议选择）的默认值对大多数人来说就是最优解，乱改反而会出问题。
回到最开始那个问题：99% 卡住能不能救？答案是——如果这个资源曾经有 BitComet 用户下载过并留在池子里，或者搜索引擎能搜到 HTTP 镜像，就能救。否则和其他 BT 客户端一样，只能等。但这已经比"完全没办法"好太多了。
本文為個人基於網路公開資料整理編寫，非官方內容，僅供學習交流參考；軟體版權歸原作者所有，請支持正版；使用過程中遇到問題請查閱官方管道，本文不承擔任何責任。
