Lightweight
轻量型客户端
体积小、启动快，适合偶尔下载与低配置设备。功能相对基础，DHT 与加密设置通常默认开启。
磁力宝不提供资源，只把 magnet 协议、DHT 节点发现、哈希校验 和 客户端设置 讲清楚。看懂了机制，下载慢、找不到节点、链接无效这些问题，大多能自己定位。
磁力链接相关的术语不多，但每一个都会影响你的使用体验。先花三分钟，把这六个词过一遍。
一种以 magnet: 开头的链接格式，用哈希值标识资源，而非指向具体文件地址。
资源的“内容指纹”，通常是 40 位十六进制字符串，唯一对应一组文件元信息。
分布式哈希表，用于在无中心服务器的情况下，根据 InfoHash 找到拥有该资源的节点。
BitTorrent 网络中的对等节点，既可能提供数据，也可能正在下载数据。
传统节点发现服务器，磁力链接可以不带 tracker，此时依赖 DHT 完成节点发现。
文件被切成多块，每块都有独立哈希值，校验不通过的块会被丢弃并重新请求。
不是所有参数都必需。真正决定资源身份的是 xt，其余大多是辅助信息。
精确主题。在 BT 场景下通常写成 urn:btih: 加 40 位十六进制 InfoHash，是磁力链接中唯一不可省略的部分。
显示名称，只用于让链接更易读。它不参与哈希校验，可以被修改，不影响资源身份。
传统追踪服务器地址。带 tr 可以让客户端更快找到节点；不带也能通过 DHT 工作，只是首连速度可能受影响。
客户端拿到 InfoHash 之后，会通过 DHT 查询拥有该资源的 peer。整个过程依赖分布式哈希表，而非某个固定服务器。
客户端从磁力链接中提取 xt=urn:btih: 后的哈希值，作为后续查询的唯一依据。
向 DHT 网络发送 get_peers 请求，逐步向更接近目标哈希的节点转发。
拥有该资源的节点会返回自身或已知 peer 的信息，客户端据此建立连接。
连接建立后交换种子元信息与数据块，开始下载并按块校验完整性。
不同客户端对 DHT、加密连接、连接数限制的默认设置不同，下载速度差异往往来自这里。
Lightweight
体积小、启动快，适合偶尔下载与低配置设备。功能相对基础，DHT 与加密设置通常默认开启。
Feature-Rich
支持连接数限制、上传策略、计划任务与远程管理，适合需要长期做种或精细调参的用户。
Cross-Platform
同时支持桌面与移动端，配置可同步。适合在电脑与手机之间切换使用的场景。
“没速度”其实分为几种完全不同的情况，对应不同的排查方向。先判断类型，再对症处理。
IDENTIFY THE SYMPTOM
MATCH THE FIX
磁力宝只讨论技术机制，不提供任何资源。磁力链接本身是一种标识方式，是否合规取决于你用它做什么。下面四条，是使用前最应该确认的事。
关于磁力链接、DHT 与客户端的几个高频问题。
.torrent 文件包含完整的种子元信息，如文件名、大小、分块哈希与 tracker 列表；磁力链接只包含 InfoHash 等少量信息，客户端需要先通过 DHT 或 tracker 获取元信息。磁力链接更轻量，但依赖网络中有活跃节点。
dn 只是显示名称，不参与哈希计算，也不影响资源身份。真正决定资源的是 xt=urn:btih: 后面的 InfoHash。改 dn 只会改变你在客户端里看到的名称。
tr 的磁力链接完全依赖 DHT 发现节点，首连速度可能稍慢，但只要网络中存在活跃 peer，仍有机会建立连接。