BitComet 断点续传 — 下载中断后从哪里接着来

什么是断点续传

你下载一个 10GB 的大文件，已经下了 7GB，突然网断了、BitComet 崩了、或者电脑重启了——如果没有断点续传，重新打开后一切从头来，前 7GB 白下了。

断点续传（Resume） 就是让客户端记住"上次下载到文件的哪个位置了"，下次启动后从那个位置继续，而不是重头再来。

BitComet 支持哪种断点续传

BitComet 的 BT 任务和 HTTP/FTP 任务都支持断点续传，但底层机制完全不同：

	BT 断点续传	HTTP/FTP 断点续传
依赖什么	torrent 分片机制	服务器是否支持 Range 请求
是否标准	BT 协议的原生特性	HTTP 协议的可选扩展
覆盖度	所有 BT 资源	部分 HTTP 服务器支持（绝大多数现代服务器都支持）
续传粒度	按 16KB~1MB 的 BT 分片	按文件的字节偏移量

BT 断点续传（原生支持）

BT 任务的断点续传是 BT 协议的原生特性，BitComet 根本不需要做额外处理：

每个 BT 分片都有独立的 SHA-1 哈希。
下载中断后，BitComet 记录"哪些分片已经下载完了、哪些还没"。
下次启动时，BitComet 先做一轮哈希校验——已经下载完的分片直接跳过，只重新请求缺失的那些。

这个机制和任何 BT 客户端完全一致。不管你用 BitComet、qBittorrent、uTorrent 还是 Vuze，BT 任务中断后都能完美续传。

HTTP/FTP 断点续传（依赖服务器）

HTTP 协议的断点续传依赖一个 HTTP 扩展头：Range。BitComet 要从断点继续下载一个 HTTP 文件时，会发送这样的请求：

GET /file.zip HTTP/1.1
Host: example.com
Range: bytes=7000000000-

意思是："我已经拿到了前 7GB 的数据，请求服务器从第 7000000000 字节开始把剩下的发给我"。服务器如果支持 Range，会返回 206 Partial Content 状态码 + 剩余的文件数据；如果不支持，会返回 200 OK + 整个文件——这就是不支持断点续传的服务器，BitComet 只能重头再来。

如何判断服务器是否支持续传

BitComet 内部做了检测，但你也可以手动验证：

发起一个 HTTP 下载任务。
下载了一点（比如 10%）后暂停。
右键任务 → "查看日志"，搜索 Range 或 206。
如果看到 HTTP 206 Partial Content 说明服务器支持，续传没问题。
如果看到 HTTP 200 OK 后从头下载，说明服务器不支持——暂停续传会失败。

或者更简单：在命令行里用 curl 测试：

curl -I -H "Range: bytes=100-" https://example.com/file.zip

返回码是 206 就支持，200 就不支持。

哪些服务器不支持

非常老的服务器：2000 年代初期的某些 HTTP 服务器软件实现不完整。
动态脚本生成的下载链接：比如 download.php?id=12345 这种 PHP/ASP 脚本，可能硬编码了 Content-Length 但不处理 Range 请求。
某些网盘直链：特别是国内一些小网盘的临时分享链接，续传支持不完整。
需要登录才能下载的服务器：Range 请求可能需要带上完整的 Cookie，稍有疏漏就被服务器当成新请求处理。

BitComet 的断点续传增强

即使服务器不原生支持 Range，BitComet 还有几个备用策略：

策略一：分片哈希校验（HTTP 下载版）

BitComet 在 HTTP 下载时也会把文件切成若干段，每段计算一个临时哈希。续传时先尝试 Range，如果失败，BitComet 会重新下载整个文件，但只覆盖那些"哈希不匹配"的段——等效于"半续传"。这个功能默认开启，在 选项 → HTTP/FTP → "分片哈希校验" 里可以关闭（关闭后完全从头下载）。

策略二：P2P 续传辅助

如果一个 HTTP 下载任务同时开了 P2P 加速，而服务器不支持续传，BitComet 可以从 P2P 对等者那里补回已经下载过的分片——因为 BT 协议的断点续传是完整支持的。这是一个很讨巧的组合拳：HTTP 源不支持续传没关系，P2P 通道支持。

策略三：已下载文件完整性保护

BitComet 会把已下载部分的数据追加写入到临时文件里，而不是每次续传时重新创建文件。这意味着即使续传过程中又断了几次，临时文件里的数据仍然是累加的——最坏情况下也是"退回到上一个稳定点"，而不是全部丢失。

断点续传的常见问题

续传后进度回退了

服务器不支持续传：Range 请求失败，BitComet 只能从头来，但你看到的已下载数据其实是"半续传"策略下的残留——临时文件里有旧数据但哈希校验不通过，BitComet 正在覆盖。等一会儿就好。
文件被服务器修改了：有些网站的文件会定期更新（比如每天刷新的压缩包），URL 没变但内容变了。这种情况下旧的续传数据和新文件哈希不匹配，必须重新下载。
BitComet 崩了：极端崩溃可能导致临时文件损坏。下次启动 BitComet 会先校验临时文件的完整性——不完整就丢弃、从头来。

为什么有些临时文件删不掉

BitComet 下载中的文件会被标记为"正在使用"，文件句柄没释放就删不掉。这是正常行为——关闭 BitComet 或先暂停对应任务后再删。

多个 BitComet 实例同时续传同一个文件

不要这么做。两个 BitComet 实例会各自维护一套临时文件和下载进度，互相覆盖。如果你的电脑上有多个 BitComet 实例在跑（比如不同用户账户下各自开了一个），确保下载目录不同、任务不同。

和其他下载器的续传兼容性

和浏览器的续传

浏览器（Chrome、Firefox、Edge）自带的下载器也支持断点续传，但浏览器之间续传文件格式不通用——Chrome 下载的临时文件 .crdownload 和 Firefox 的 .part 不能互通。BitComet 的临时文件格式也不兼容浏览器的，浏览器没下完的文件 BitComet 接不上，反过来也一样。

和其他下载器的续传

IDM、迅雷、Free Download Manager 各自都有自己的临时文件格式，互不兼容。能跨客户端续传的只有 BT 任务——因为 BT 协议的分片和哈希校验是标准的，任何客户端都能接上。

如果想把浏览器没下完的任务转给 BitComet

理论上做不到（临时文件格式不匹配）。但有一个 workaround：

在浏览器里找到下载中断的那个文件的真实 URL（不是浏览器显示的临时文件名）。
把这个 URL 粘贴到 BitComet 里作为新的 HTTP 任务，保存路径选和浏览器临时文件同一个目录、同一个文件名。
BitComet 会发现这个文件已经存在，自动先做 Range 请求尝试续传——服务器支持的话，就从断点继续了。

这个方法不是每次都成功（取决于浏览器临时文件的格式和服务器对续传的支持），但值得一试。