磁力链解析这个需求我在三类不同形态的项目里都实打实做过一个是资源索引服务每天要吞掉几十万条用户提交的 Magnet URI必须在一秒内完成校验、归一化和去重一个是桌面端小工具用户粘贴一条链接进去程序得把 infohash、显示名、tracker 全拆出来摆在界面上还有一个是纯数据清洗的活几百万条历史数据里混着各种畸形写法需要洗成统一格式。三次下来我攒了一套相对稳定的Java 解析磁力链方案也把能踩的坑基本踩了一遍。这篇文章就把这套东西完整摊开Magnet URI 到底由哪些部分组成、每一段该怎么解、为什么new URI(...).getQuery()会在第一步就给你返回 null、Base32 和 Hex 怎么安全互转、批量解析怎么把耗时压下来、线上真出问题时怎么五分钟定位。内容偏实操代码都能直接抄去改适合正在做下载器、资源索引后台、数据清洗或者单纯想搞明白磁力链结构的朋友。1. 先把 Magnet URI 拆开看它到底是一串什么1.1 一条真实链接的逐段解剖拿一条典型的长链接来看写成下面这样我做过换行处理实际是一整行magnet:?xturn:btih:c12fe1c06bba254a9dc9f519b335aa7c1367a88a dn%E6%B5%8B%E8%AF%95%E8%B5%84%E6%BA%90 trudp%3A%2F%2Ftracker.example-a.net%3A6969%2Fannounce trudp%3A%2F%2Ftracker.example-b.net%3A1337%2Fannounce xl734003200 so0-2,4拆开看magnet:是协议头紧跟着一个?后面就是标准的keyvaluekeyvalue查询串。注意这里没有//也没有主机名和路径——这是很多人第一次写解析器时最不习惯的地方。xt是 exact topic精确主题值是urn:btih:加上 40 位十六进制的 infohashdn是 display name显示名被百分号编码过tr是 tracker 地址可以出现多次xl是 exact length内容总字节数so是 select only表示只下载指定序号的几个文件。我把这些参数整理成一张表你写解析器的时候可以直接照着建模型参数名语义是否必需典型取值常见写法问题xt精确主题标识必需可多条urn:btih:40hex或urn:btih:32base32Base32 没转成 Hex、大小写混杂dn显示名可选百分号编码的 UTF-8 串被当空格、编码被截断trTracker 地址可选可多条udp://...、http://...从网页抓来变成amp;trxl内容字节长度可选十进制整数超过 int 范围被截断wsWeb Seed 直链可选可多条http(s)://...协议不可信、未做校验so只选部分文件可选0-2,4区间语法解析漏掉边界kt关键词可选编码后的词分词场景下容易重复这张表里最关键的一行是xt。很多新手写的解析器只看长度40 位就当 Hex32 位就当 Base32然后直接把 32 位那串塞进数据库。结果下游拿去请求元数据时全部失败——因为它要的是 20 字节的二进制摘要你给了一串没解码的 Base32 文本。这个坑我在数据清洗项目里遇到过整整一版数据需要重跑代价不小。1.2 为什么它是元数据请求而不是地址理解这一点很多设计决策就自然通了。普通的 HTTP 链接指向一个确定的位置你知道文件在哪台机器上、用什么路径取。磁力链不是它只给了一个摘要指纹和几个可能知道这个文件的人的地址。真正的下载流程是客户端拿着 infohash 去找 DHT 网络或者 tracker问谁有这个内容拿到 peer 列表后连上去再交换元数据种子文件里的文件树、分片大小等最后才开始传数据。这就解释了两个现象。第一为什么磁力链可以不带 tracker 也能用——DHT 本身就是一张分布式哈希表infohash 就是这张表的 key。第二为什么 infohash 必须规范化同一个内容的 Hex 大写、Hex 小写、Base32 大写三种写法在字符串层面完全不同但指向的是同一份数据。你的系统里如果不去重同一个资源会被当成三条记录索引膨胀三倍用户看到三个一模一样的结果。注意解析器的输出必须包含一个归一化后的 infohash而不是只保留原始字符串。归一化规则我后面会写核心是统一转成 40 位小写 Hex。1.3 解析器要做到什么程度先把边界划清楚在动手之前我建议先把需求边界定死。一个解析器只需要做四件事把 URI 拆成键值对、对值做正确的百分号解码、把xt里的摘要解码成二进制并归一化、把结果装进一个不可变对象。它不需要做的是验证 tracker 是否真的活着、校验 infohash 在 DHT 上是否真实存在、判断内容是否完整。这三件事属于网络层放进解析器只会让它变慢、变得不可测试。我把边界定成这个样子的另一个原因是可测试性。纯函数的解析器输入字符串、输出对象没有网络、没有数据库、没有时间依赖单元测试可以写几百条跑完不到一秒。一旦你把顺手校验一下 tracker 连通性塞进去测试就得依赖网络环境CI 上三天两头挂。还有一条边界得说清楚解析器面对的输入是完全不可信的外部数据。用户提交的、从网页抓来的、从旧数据库导出的什么都可能有。所以我的原则是宁可抛异常不要返回半个对象。一个 infohash 长度不对的链接与其返回一个残缺的 MagnetLink 让下游去判空不如直接抛IllegalArgumentException让调用方在入口处就把它拦掉。这里的代码实践仅面向有合法授权的数据场景具体业务怎么用各自把握。2. Java 解析方案选型三条路我都走过2.1 方案一java.net.URI为什么它会在第一步就绊倒你看到 URI很多人的第一反应是new URI(magnet).getQuery()。我第一次也是这么写的跑了个单元测试getQuery()返回null当时以为是链接格式有问题换了一条正常的还是 null。原因在 RFC 3986 的语法里magnet:?xt...这种形式没有//属于opaque URI不透明 URI。对于 opaque URI?后面的全部内容被整体当作 scheme-specific part框架不会再去拆查询串所以getQuery()就是 null。你要拿内容只能走getRawSchemeSpecificPart()返回值是?xturn:btih:...自己把开头的?剥掉。而magnet://?xt...这种多写了两个斜杠的写法反而是 hierarchical URI层级 URIgetQuery()能正常返回。于是出现一个很反直觉的现象格式不太规范的写法在你的代码里工作正常规范的写法反而解析不出来。这个差异如果不搞清楚排查起来能耗掉一下午。再往下还有第二个坑URI构造器对非法字符很严格。dn里如果出现未编码的空格、中文、|、{、}new URI(...)直接抛URISyntaxException。而现实数据里未编码的中文显示名太常见了。所以我的结论是java.net.URI可以用来做协议头合法性校验但不要指望它帮你拆参数。2.2 方案二正则一把梭快但脆第二条路是一条正则搞定Pattern.compile(magnet:\\?(.*), Pattern.CASE_INSENSITIVE)再配一个([^])([^]*)去遍历。写起来确实快二十行搞定。但我用了一段时间后放弃了原因有三个。第一正则的回溯风险。当输入超长有些爬来的链接 dn 里塞了几千个字符且格式不规范时([^])([^]*)这类模式在某些边界输入下回溯量会飙升。我做过压测十万条正常链接跑下来没问题但混入 1% 的超长畸形串后总耗时从 800ms 涨到 6s 多。第二正则不好做部分容错。我想实现遇到坏的键值对跳过、继续解析剩下的用正则写会变成层层嵌套的判断可读性极差。第三正则表达式没法给出精确的错误位置日志里只能说这条链接解析失败定位还得靠人工复现。不是说正则不能用我现在的做法是只在快速判断这是不是一个 magnet 链接这个场景用前缀判断regionMatches真正的解析走手写扫描。2.3 方案三手写轻量扫描器我最终的选择最终方案是一个基于indexOf的单遍扫描器从magnet:后面开始逐个找切出一段keyvalue再找第一个分开键和值对值做百分号解码塞进MapString, ListString。整个过程零正则、零临时对象爆炸十万条链接解析耗时稳定在 500ms 以内单核含 Hex 归一化。关键设计有几个。用LinkedHashMap而不是HashMap保证参数顺序稳定便于日志比对和单元测试断言。用MapString, ListString而不是MapString, String因为tr、ws天然可重复用单值 Map 会丢数据。键统一toLowerCase(Locale.ROOT)因为现实中有XT、Dn这种大写写法协议层面参数名是大小写不敏感的。用Locale.ROOT而不是默认 Locale是因为土耳其语环境下I.toLowerCase()会变成ı无点小写 i这个坑在跨国部署时是真实存在的。还有一个细节先切分再解码。绝对不能先把整个字符串解码成明文再去按和切因为值里可能出现被编码的%26也就是和%3D也就是。如果你解码在前dnTom%26Jerry会变成dnTomJerry然后被错误地切成两段。顺序错了这类数据必挂。3. 核心字段逐个攻破每个参数都有自己的脾气3.1 xt多值、大小写与 urn:btih / urn:btmh 前缀xt是唯一必需的参数也是最容易出错的一个。它的完整形态是urn:btih:hash其中urn是统一资源名btih表示 BitTorrent InfoHash。有些新格式会用urn:btmh:这里的mh指 multihash多哈希用来承载 SHA-256 版本的 infohash长度是 32 字节而不是 20 字节。处理xt的第一条规则它可以出现多次。一个链接里同时带urn:btih:和urn:btmh:是很正常的客户端应该优先用能识别的那个或者两个都存下来。我见过有实现只取params.get(xt).get(0)结果拿到的是它不认识的那个直接判定解析失败。正确做法是遍历所有xt值逐个尝试识别前缀把能识别出来的都收集起来。第二条规则前缀匹配要大小写不敏感。URN:BTIH:也是合法的虽然少见。第三条规则值里可能有空白。有些从聊天软件复制出来的链接中间被插入了换行或者空格。我的处理是在解码之后对摘要部分做一次trim()把首尾空白去掉。注意只对摘要做 trimdn里的空格是有意义的不能动。3.2 Base32 与 Hex20 字节的两种马甲这是整个解析里技术含量最高的部分。infohash 的本质是 20 字节v1或 32 字节v2的二进制摘要值磁力链里用两种文本编码来表示它Hex十六进制40 个字符每个字节用两位0-9a-f表示信息密度 4 bit/字符。Base3232 个字符用A-Z和2-7共 32 个符号表示信息密度 5 bit/字符。20 字节 × 8 160 bit160 ÷ 5 32 字符正好整除。为什么会有 Base32 这一种因为早期一些场景下比如文件名、某些只允许字母数字的输入框大小写不敏感的编码更安全。Hex 里a和A是同一个值但 Base32 天然只有大写避免了大小写歧义。解码 Base32 的核心逻辑是一个位缓冲区public final class Base32 { private static final char[] ALPHABET ABCDEFGHIJKLMNOPQRSTUVWXYZ234567.toCharArray(); public static byte[] decode(String input) { String s input.toUpperCase(Locale.ROOT).replace(, ); byte[] out new byte[s.length() * 5 / 8]; int buffer 0, bitsLeft 0, idx 0; for (int i 0; i s.length(); i) { int v indexOf(ALPHABET, s.charAt(i)); if (v 0) { throw new IllegalArgumentException(非法 Base32 字符: s.charAt(i)); } buffer (buffer 5) | v; bitsLeft 5; if (bitsLeft 8) { out[idx] (byte) ((buffer (bitsLeft - 8)) 0xFF); bitsLeft - 8; buffer (1 bitsLeft) - 1; // 清掉已输出的高位防止 int 溢出 } } return Arrays.copyOf(out, idx); } }这段代码有两个地方值得单独说。第一是buffer (1 bitsLeft) - 1这一行很多人会省掉。省掉之后buffer的高位垃圾会一直累积遇到长输入时buffer 5可能把有效位挤出 int 范围导致后半段解码错乱。32 个字符的输入其实还撑得住但你要是拿这个方法去解更长的 Base32比如某些扩展格式必翻车。第二是输出数组预分配s.length() * 5 / 832 字符算出来是 20正好不需要动态扩容。Hex 转换反过来更简单但我建议用查表而不是String.format(%02x, b)private static final char[] HEX 0123456789abcdef.toCharArray(); public static String toHex(byte[] bytes) { char[] out new char[bytes.length * 2]; for (int i 0; i bytes.length; i) { int b bytes[i] 0xFF; out[i * 2] HEX[b 4]; out[i * 2 1] HEX[b 0x0F]; } return new String(out); }String.format内部要走 Formatter一条链接一个 infohash 看起来无所谓但十万条就是十万次 Formatter 调用。我实测过换成查表后归一化环节的耗时下降了约 60%。实操心得长度判断要放在解码之前而且两条路都要校验最终字节数。40 位 Hex 解出来必须是 20 字节32 位 Base32 解出来也必须是 20 字节。如果解出来是 19 字节说明输入里有非法字符被吞了必须报错。3.3 dnURL 解码里那两个经典陷阱dn是显示名用户最直观看到的东西也是最容易乱码的地方。有两个陷阱必须点破。第一个是号。在application/x-www-form-urlencoded规范里代表空格。但在 URI 的路径和查询串规范里就是一个普通的加号字符空格应该是%20。磁力链更接近后者。于是问题来了如果你用URLDecoder.decode()dnMovie2024会被解成Movie 2024而原意可能是Movie2024比如某些名字里真的有加号。反过来如果生成方遵循了表单编码习惯把所有空格写成你不用URLDecoder就会得到一堆。我的处理是默认把当普通字符因为磁力链的规范里它是普通字符只对明确来自表单提交场景的输入做二次兼容处理。这个决策要在文档里写清楚不然下游会困惑。第二个是编码参数。URLDecoder.decode(String)这个重载在 Java 8 里只有(String)版本用的是平台默认字符集。服务器上如果 LANG 没配好默认是 ISO-8859-1中文dn全部变乱码。Java 10 之后有了decode(String, Charset)重载一定要用带 Charset 的版本显式传StandardCharsets.UTF_8。如果你还被锁在 Java 8那就自己写解码方法别偷懒。第三个容易被忽略的是编码截断。从网页或者日志里复制出来的链接末尾经常被截掉几个字符留下一个孤零零的%E4。这时候解码会抛异常。我的做法是捕获这个异常记录原始值把dn置为空串而不是让整条链接解析失败——因为 infohash 可能还是好的资源还能用。3.4 tr / xl / ws / so扩展参数该怎么存tr是 tracker 列表可以重复出现。存储上用ListString而且要去重。我在线上数据里见过同一条链接里同个 tracker 重复出现七次的不做去重会让下游的连接池白白多开六次。xl是内容字节数解析成long。不要用int——4GB 上限在视频资源面前完全不够。Long.parseLong遇到超出范围会抛NumberFormatException捕获后置 0 或者置 -1别让它中断整个解析。有些实现还会用BigInteger我觉得没必要long上限 8EB够用到天荒地老。ws是 web seed直链地址可能有多条。存的时候要顺手校验协议前缀只接受http://和https://。为什么因为后面你可能要拿这个地址去发起请求如果协议是file://或者别的东西就是安全隐患。so是 select only语法是逗号分隔的索引或区间比如0-2,4,7-9。解析成Listint[]每项是[start, end]。要注意0这种单个数字表示只要第 0 个文件等价于0-0。还要注意边界越界的情况——so999但资源只有 10 个文件这个判断解析器做不了得留给元数据下载之后。我一般会额外保留一个extra字段把不认识的参数原样存进MapString, ListString。这样做的好处是以后协议扩展了新参数你的老代码不用改也能把它们透传下去。4. 完整实现一个能上生产的解析器4.1 结果模型与不可变设计模型我用不可变类Java 14 可以直接上 recordJava 8 就用 final 字段加构造器public final class MagnetLink { private final String raw; // 原始输入方便排查 private final String infoHashHex; // 归一化后的 40 位小写 Hex private final String infoHashV2Hex; // v2 摘要可能为 null private final String displayName; // 可能为空串不为 null private final ListString trackers; // 已去重 private final ListString webSeeds; private final long exactLength; // 未知时为 -1 private final Listint[] selectOnly; private final MapString, ListString extra; // 构造器 只读 getter集合字段返回 Collections.unmodifiableList(...) }为什么强调不可变因为这类对象经常会跨线程传递——接收线程解析完丢进队列工作线程从队列里取。可变对象一旦有人手滑改了trackers问题会在几百行之外爆发排查成本极高。返回unmodifiableList还有一个好处能立刻暴露那些想顺手往列表里塞一个默认 tracker的代码。4.2 解析主干代码主干分四段校验前缀、剥壳、切参数、组装对象。public final class MagnetParser { private static final String SCHEME magnet:; public static MagnetLink parse(String raw) { if (raw null) { throw new IllegalArgumentException(输入为 null); } String s raw.trim(); if (s.isEmpty()) { throw new IllegalArgumentException(输入为空串); } if (!s.regionMatches(true, 0, SCHEME, 0, SCHEME.length())) { throw new IllegalArgumentException(不是 magnet 协议: preview(s)); } int i SCHEME.length(); while (i s.length() s.charAt(i) /) { // 容忍 magnet:// i; } if (i s.length() s.charAt(i) ?) { i; } if (i s.length()) { throw new IllegalArgumentException(缺少查询参数); } MapString, ListString params splitQuery(s.substring(i)); return assemble(raw, params); } }while (i s.length() s.charAt(i) /)这个循环看着小题大做但它同时兼容了magnet:?、magnet://?、magnet:///?三种写法。现实数据里这三种我都见过。用while而不是if是因为曾经有一次抓到过三条斜杠的输入用if就漏了。切分函数private static MapString, ListString splitQuery(String query) { MapString, ListString map new LinkedHashMap(); int start 0, len query.length(); while (start len) { int amp query.indexOf(, start); if (amp 0) { amp len; } if (amp start) { String pair query.substring(start, amp); int eq pair.indexOf(); String key eq 0 ? pair : pair.substring(0, eq); String val eq 0 ? : pair.substring(eq 1); key key.trim().toLowerCase(Locale.ROOT); if (!key.isEmpty()) { map.computeIfAbsent(key, k - new ArrayList(2)).add(urlDecode(val)); } } start amp 1; } return map; }注意eq 0的分支有些链接会写成tr没有等号直接跳过这个键值对会影响后续所以按键存在、值为空处理。还有key.trim()因为从网页复制过来的链接里后面经常跟着空格。4.3 归一化、去重与校验组装阶段最关键的是xt的处理。我把它独立成一个静态方法public static String normalizeBtih(String value) { String v value.trim(); if (v.regionMatches(true, 0, urn:btih:, 0, 9)) { String h v.substring(9).replace(, ); if (h.length() 40) { for (int i 0; i 40; i) { if (Character.digit(h.charAt(i), 16) 0) { throw new IllegalArgumentException(btih 含非法十六进制字符); } } return h.toLowerCase(Locale.ROOT); } if (h.length() 32) { byte[] bin Base32.decode(h); if (bin.length ! 20) { throw new IllegalArgumentException(Base32 解码长度异常: bin.length); } return Base32.toHex(bin); } throw new IllegalArgumentException(btih 长度非法: h.length()); } if (v.regionMatches(true, 0, urn:btmh:, 0, 9)) { // v2 摘要多哈希格式0x12 表示 SHA-2560x20 表示 32 字节 return normalizeBtmh(v.substring(9)); } throw new IllegalArgumentException(不认识的 xt 前缀: preview(v)); }urn:btmh的处理稍微绕一点。它的值通常是 65 位十六进制前两位12是哈希算法标识0x12 对应 SHA-256中间两位20是摘要长度0x20 32 字节后面 64 位才是真正的摘要。也有用 multibase 前缀b加 Base32 的写法。我的策略是优先解析十六进制形态遇到不认识的就整条跳过而不是报错因为 v1 摘要通常同时存在。去重逻辑有两处。tracker 列表用LinkedHashSet保序去重最后转List。整条链接的去重则靠infoHashHex做主键这个我放到下一节讲。4.4 测试用例清单含 12 条畸形输入解析器的测试重要性远高于普通业务代码因为输入完全不可控。我整理了一份必测清单你写的时候可以直接拿去用编号输入特征期望行为1标准 40 位 Hex dn 2 个 tr全部字段正确232 位 Base32 摘要正确转成 40 位 Hex3magnet://?xt...双斜杠正常解析4MAGNET:?XT...全大写正常解析5dn 含%E4%B8%AD%E6%96%87正确解出中文6dn 含未编码空格不抛异常原样保留7尾部%E4截断dn 置空其余字段正常8xt出现两次v1 v2两条摘要都保留9xl99999999999正确解析为 long10tr重复出现 7 次去重后剩 1 条11完全不是 magnet 协议抛 IllegalArgumentException12空串、null、纯空格抛 IllegalArgumentException第 8 条经常被忽略。我最早写的版本是取第一个能识别的 xt后来发现某些客户端会先放 v2 摘要老代码不认识urn:btmh:就跳到下一个其实没问题但另一些客户端把 v2 放在后面老代码取了第一个 v1 就停导致后面的信息丢了。现在的做法是全部遍历一遍。第 10 条我给的建议是实现层面去重而不是测试时人工清理。理由很实在去重是一行代码的事人工清理是无穷无尽的事。5. 线上排查实录五种最常见的坏数据5.1 症状 → 原因 → 修法速查表线上跑久了你就会发现失败案例高度集中。我把遇到过的整理成表症状最可能原因修法getQuery()返回 null用了java.net.URI解析 opaque URI改用getRawSchemeSpecificPart()或自写扫描器infohash 长度是 32Base32 没解码直接当字符串存了加 32 位分支解码成 20 字节再转 Hex中文显示名全是乱码URLDecoder用了平台默认字符集显式传StandardCharsets.UTF_8tracker 变成amp;tr...从 HTML 抓的链接里amp;没还原解析前先把amp;替换成显示名里多出一堆空格被当成了空格判断来源非表单场景不处理解析超时、CPU 飙高正则回溯或输入超长导致字符串拼接爆炸换手写扫描加长度上限表格里最值得单独讲的是第四条因为它的表现形式很隐蔽。5.2 从网页抓来的链接为什么全军覆没我第一次做网页采集的时候抓下来一批链接解析出来trackers是空的但日志显示参数明明存在。打印原始字符串才发现长这样magnet:?xturn:btih:xxxamp;dntestamp;trudp%3A%2F%2F...HTML 里必须写成amp;才是合法的浏览器渲染时会把amp;显示成但如果你直接拿 DOM 的 innerHTML 或者原始响应文本拿到的就是amp;。你的切分逻辑按切第一段是xt...第二段是amp;dntest键名变成了amp;dn自然找不到dn。更麻烦的是tr全被吞掉因为每个tr前面都带着一个amp;。处理方法很简单解析入口处做一次预处理s s.replace(amp;, )而且要在切分之前做。但要小心别误伤——如果一个dn的值里真的有字面量amp;被正确编码成%26amp%3B替换不会影响它因为它在解码之前还不是。这个顺序要理清先替换 HTML 实体再切分最后百分号解码。顺带说一句同样的坑还有lt;、gt;、quot;出现在显示名里。我的做法是在解码之后对显示名做一次实体还原别在原始串上做。5.3 性能十万条链接跑多久性能这块我做过完整的压测环境是单核 2.4GHz输入是十万条真实结构的链接其中 5% 是畸形串。第一版用正则平均 6.2 秒P99 单条 3ms最慢的一条 800ms就是那条超长 dn 的。第二版换成手写扫描平均 480msP99 单条 0.2ms最慢 2ms。第三版加了StringBuilder复用和字符数组直读降到 310ms 左右。优化的关键其实不在算法而在避免无谓的对象创建。比如不要用split()它会创建数组和一堆子串不要用String.format生成 Hex不要在循环里用拼字符串。还有一个容易忽略的点substring在 Java 7u6 之后是拷贝而不是共享底层数组所以少 substring是真的能省内存。注意事项如果你的服务要长期跑批量解析建议在入口加一个长度上限比如单条链接超过 8192 字符直接拒绝。我遇到过攻击性的输入单条链接 10MB全是拼起来的垃圾参数不设限的话内存直接被拉爆。6. 解析之后落库、展示与看不见的风险6.1 主键、去重与索引设计解析出来只是第一步真正的价值在于把数据管好。我的建议非常明确用归一化后的 40 位小写 Hex 做主键其余所有字段都是它的属性。为什么不用原始链接因为同一条链接在不同时间抓取dn可能变了、tr可能变了、参数顺序也可能变了用原始串做主键会产生大量重复。infohash 是内容指纹一个指纹对应一份内容天然唯一。去重的时机放在入库前。我一般会做一次批量查询把这批数据的 infohash 列表拿去查一次数据库拿到已存在的集合然后只插入新的。批次大小控制在 500 到 1000 之间太大容易触发 SQL 长度限制太小网络往返次数太多。还有一个细节合并策略。当发现库里已有同一个 infohash 时不要简单跳过而应该做字段合并——新数据里如果有更长的dn有些名字被截断了、更多的tr、更准确的xl就应该更新。我的规则是dn取更长的那个tr取并集xl在原来为 -1 时用新值覆盖。这套规则跑下来数据质量比新覆盖旧和旧的不要动都好。索引方面主键上建唯一索引dn上建前缀索引用于搜索xl上加普通索引用于按体积筛选。如果要做全文检索dn单独同步到搜索引擎别在主库上跑LIKE %xxx%。6.2 非信任输入的三道防线解析器产出的对象最终会流到各个地方数据库、前端页面、文件系统、甚至作为参数去发网络请求。每一处都要设防。第一道防线是数据库层。用预编译语句绝不拼 SQL。dn里出现和\太正常了我在测试数据里塞过Robert); DROP TABLE这样的名字拼 SQL 的实现必挂。第二道防线是展示层。dn是用户可控的前端渲染时必须转义。我在一个内部管理后台见过dn里塞了img srcx onerror...页面直接执行了脚本。服务端渲染也好、前端框架也好该转义的地方一个都不能省。第三道防线是出站请求层。这一条最容易被忽略。tr和ws都是外部可控的 URL如果你拿它们去发起请求必须做三件事一是白名单校验协议只允许http/https/udp二是解析目标 IP 并拒绝内网地址段否则就是经典的请求伪造三是设置超时上限。我做过一个安全评审发现某个服务会拿ws字段直接去发请求攻击者构造一个指向内网管理端口的地址就能探测内网存活风险很实在。还有一个和业务无关但很实用的建议dn如果要用作文件名必须做路径清洗。把它里面的/、\、..、:全部替换掉Windows 上还要避开那几个保留名。这些处理放在文件落地之前别等到磁盘写满了才发现。6.3 我个人踩坑最多的一条经验如果只能留一条经验我会说别相信任何一条链接的格式正确性但也不要因为它格式错误就整条丢掉。我最早的做法是要么全对要么抛出结果数据清洗项目里 37% 的链接被判定为失败。人工抽样看了两百条发现其中大部分只是dn尾部被截断或者某个tr少了协议头infohash 完全正常。改成分级容错之后——核心字段xt失败就整条拒绝非核心字段dn、tr、xl失败就置空继续——失败率降到 0.3%而且剩下的 0.3% 确实是垃圾。具体的做法是给每个字段配一个容错解析器内部try-catch失败时返回默认值同时把错误记到一个parseWarnings列表里。这个列表在生产环境特别有用你可以按警告类型做聚合统计看看最近是不是某个来源的数据质量整体下降了。我靠这个手段提前发现过一个采集源的 HTML 结构改版比用户反馈早了两天。最后再分享一个习惯。我所有解析器的第一个参数都是raw并且原样保存在结果对象里。这条原始字符串在上线后的前三个月救过我至少五次——出问题时我可以直接从日志里把原始串捞出来扔进单元测试复现、修复、加回归用例整个过程不超过十分钟。如果只存了解析后的字段你就只能靠猜。