磁力链接的结构与索引平台的工作方式
磁力链接由哪几部分组成
一条完整的磁力链接以 magnet:? 开头，后面跟着若干参数。其中最关键的参数是 xt，它携带的是资源的哈希值，通常以 urn:btih: 作为前缀。除此之外，dn 参数给出建议的文件名，tr 参数列出一组 Tracker 地址，用于协助寻找持有相同文件的节点。文件名只起提示作用，可以被人为修改；Tracker 地址也可能失效或被替换。真正决定一条链接指向何处的是哈希值，其余参数都属于辅助信息，缺失时链接仍然可以使用。
哈希值如何决定资源身份
哈希值由文件内容计算得出，内容只要有一个字节不同，结果就会变化。因此同一个文件即便被改过名字、换过目录，只要内容未动，哈希值就保持一致，指向的仍是同一份资源。反过来，两个体积相近、名字相似的文件，哈希值往往完全不同。索引平台据此判断重复：新条目入库前先比对哈希值，命中已有记录就合并，而不是新增一条。这样一来，同一资源的不同命名不会在列表里反复出现，用户看到的条目数量也更接近真实数量。
索引平台在中间做了什么
索引平台本身不保存文件，只记录链接、文件清单与字段信息。工作流程大致是：抓取公开的链接文本，解析出哈希值与文件名，校验链接是否仍然可用，再把结构化字段写入索引。整理阶段会对条目重新校验，失效的链接被标记，长期无法访问的记录从列表中移出。用户看到的结果页，其实是这些字段经过筛选与排序后的呈现。理解这一点，有助于判断一条结果为何排在前面，也有助于理解为何某些链接点开后无法继续。
用户评论
十条使用后的留言，按提交时间排列
按体积区间筛选这个功能挺实用，以前翻十几页都找不到合适的，现在两三个字段一填，结果就收敛了。
详情里的文件清单按体积排序，一眼就能看出哪个是正片哪个是花絮，省了不少点开确认的功夫。
校验状态直接写在列表上这点不错，失效的链接不用点进去试，节省下来的时间够多看两条。
收录日期标得很清楚，想找近一个月的内容直接按时间排序就行，不用自己拿笔记，翻页也快。
同一资源被改了七八个名字的情况终于不用一条条对比了，合并之后列表干净很多。
移动端筛选条收起来之后页面清爽不少，展开也不卡，通勤路上用手机查资料方便了许多。
收藏清单存的是筛选条件不是结果，这点设计得挺懂行，索引变了重新套一次就行。
解析粘贴的链接时返回的文件数量挺准，比之前用的几个工具靠谱，界面也不花哨。
排序状态记在地址栏参数里，刷新之后还是原来的顺序，这个小细节做得挺到位，用着顺手。
整体结构清楚，八个方向分栏之后找东西有路径可循，不会像无头苍蝇一样乱点一通。