企业官网建设流程全解析

Bilibili-thread-ripper（BTR，线程撕裂者）是一款面向海外用户的 B 站多线程下载插件，它模仿 IDM 的思路，把一段视频流拆成多个 HTTP Range 请求，由多条连接、多个 CDN 节点并发下载，解决海外用户看 B 站卡顿、转圈的难题，让 8K、4K、杜比视界视频也能流畅播放。下面用尽量少的代码，讲清楚它"怎么撕裂、怎么拼回、怎么调线程"的完整原理。

一、为什么海外看 B 站会卡：一条连接跑不满码率

B 站官方把 CDN 分成三层：离用户最近的边缘节点、兜底的区域骨干节点、存着所有视频的源站核心机房。边缘节点"就近服务、只缓存热门数据"，这带来一个后果——海外看热门视频很快，但冷门视频的海外边缘节点上没有缓存，只能绕回更远的节点取数据。

而网页播放器的默认行为是：一段数据只开一条连接。这条连接在海外冷门视频上经常只有几 Mbps，一旦码率一高（比如片源码率 20 Mbps 的杜比视界 4K60），缓冲立刻见底，播放器开始转圈。这就是卡顿的根源。

二、IDM 式核心动作：把一段切成多个小块，多连接并发下载

BTR 的做法和 IDM 下载文件时的多线程如出一辙，核心只有一步：把"一条连接下完整个分段"改成"多条连接各下一段中不同的小块"。

1. 切块：播放器需要某一段视频时，BTR 按并发数把这段字节区间切成若干块，每块最小约 64 KiB，并根据实测单连接速度自适应调整块大小，让每条连接都"忙得起来"。切块逻辑见 splitRange。
2. 并发拉取：每条连接发一个带Range: bytes=起始-结束头的请求，拿的是文件里不同的部分，不会把同一块数据重复下载。核心下载器在 src/idm-downloader.js 中实现。
3. 核对：服务器必须返回206 Partial Content，且响应头里的Content-Range必须与请求的字节区间完全一致，块长度也必须分毫不差，否则这块数据直接丢弃。解析与校验在 parseContentRange。
4. 拼接：所有块到齐后按顺序拼回完整分段，交给播放器。哪个块位置或长度不对，绝不会被塞进缓冲区，见 concatChunks。

全接管模式下，BTR 直接把数据写进网页里的 B 站原生播放器（src/native-mse-player.js），弹幕、清晰度菜单、倍速都照常可用；兼容模式下则保留 B 站播放器，BTR 只负责下载它的媒体请求（src/native-range-transport.js）。

三、不只是堆线程：一套为"播放"服务的调度器

真正的精华在于：BTR 不是简单开 N 条线程，而是在多个 CDN 之间做了一套为播放服务的调度（见 src/cdn-resolver.js 与 src/idm-downloader.js）。

① 多节点并发 + 按速度分配。大陆模式内置一批大陆节点（MAINLAND_HOSTS），海外模式另有一组海外节点，还可以手动添加自定义服务器。每个小块的"首选节点"按实测速度加权轮转分配（assignPrimaries）：最快的节点分到最多的小块，速度慢到只有最佳节点 1/12 的直接不参与；没有实测记录的节点会拿到末尾的小块"试工"，测出速度后再重新排座次。

② 对冲副本（hedging），慢了就另开一条路。对每一块，BTR 会持续盯着第一份副本的进度；一旦发现它明显慢于常规速度、或者按当前速度赶不上"播放时刻"，就立刻从已知最快的节点再发一份副本去救。谁的先下完就用谁，另一份立即取消（hedgeDue）。

③ 断点续传，失败不整块重来。某块中途断了，已收到的部分会保留，重试或副本请求只补缺少的尾巴，而不必从头再下。坏节点会被"封禁名单"记小过，两次无字节返回就本场停用（createBanList），过段时间再给机会。

④ 离播放越近，优先级越高。每个请求都带一个"播放截止时刻"，队列按截止时间的紧迫度排序，带宽优先保证马上要播的内容；只有判断某块可能赶不上播放，才动用有限的"救援名额"多开副本，尽量不浪费流量。

⑤ 起播探测。打开视频的第一时间，BTR 先在多个节点之间"竞速"抢下一小段开头数据（哪个节点最快立刻可测），再用测出的速度把后续小块分出去——所以高码率视频开头不再动辄转圈。分段本身的位置信息则来自 fMP4 的 sidx 索引，由 parseSidx 解析。

效果上，同一个杜比视界 4K 视频，从不开插件的 7.5 Mbps 提升到 40 Mbps 以上（墨尔本 Superloop 实测，仅供参考）：

四、自动线程数：插件自己决定开 8 还是 64 条线程

线程数不是拍脑袋设的。BTR 内置一条"自动线程数"阶梯[8, 12, 16, 24, 32, 48, 64]（AUTO_LADDER），规则非常"讲究"：

• 起步加码：每次开始播放先用 16 条线程冲刺，等前方缓冲攒够约 15 秒，再一档一档降回页面原有水平；
• 压力升档：播放器卡顿、低缓冲涨不动、连接排队等首字节太久时，自动升一档；
• 试错回退：每次升档都是一次"试验"，10 秒后吞吐量没有变快，就降回原档位并休息一阵——多开的连接如果没有带来收益，只会增加风险；
• 服务器拒绝即退：遇到 HTTP 412/429（服务器拒绝当前负载）立即降档，并在较长时间内不再冲过该档位。

连接总数由一个信号量统一控制（Semaphore），所有请求排队取号，保证同一时刻的并发不超过设定值。设置里也可以手动选 4～128 条固定线程：

官方建议：一般情况选「大陆 CDN + 自动线程数」；设备性能弱可手动降到 4～8 线程；本地连大陆网络差则用海外 CDN。

五、怎么知道它在工作

• 设置面板会显示当前总线程数，偶尔显示 0 是正常的（说明缓冲已足够）；
• 播放器右键「视频统计信息」里的节点、速度、分段是插件真实的下载数据，Player Type 一行显示BTR Native；
• 进度条前方的缓存持续增长，说明数据正在正常交给播放器。

设置入口有三个：页面上的 BTR 悬浮球、脚本管理器菜单、播放器「更多播放设置」。以暴力猴为例：

六、效果边界：它变不出带宽

另外提醒：BTR 只优化你已有权访问的媒体数据，不会绕过会员、登录、区域或版权限制，也不上传任何遥测数据。更多细节可看 README.md 的原理解释章节和 CHANGELOG.md 的更新记录。