Bilibili 线程撕裂者

目录

• 安装
• 建议设置
• 更新历史
• 原理解释
• 怎么知道插件到底有没有工作
• 当前版本保留了哪些 B 站功能
• 常见问题
• 反馈问题
• 开发与构建
• 开源协议

一个真的能解决海外用户B站卡顿的 Chrome 插件 当前版本：0.9.1.5

更新历史： updates.md

很多海外用户的宽带明明很快，打开 B 站热门视频也没什么问题，但是一到冷门视频、4K、4K 60 帧就开始卡。传统 CDN 优选插件只是换一个节点，换完以后本质上还是单连接下载。碰到冷门资源或者单连接限速，照样该卡就卡。

线程撕裂者不再赌某一个 CDN。它会把 B 站的视频分段继续拆成多个字节块，像 IDM 一样并发下载，下载完成后按原顺序交给播放器。

0.9.x 已经不再替换 B 站播放器。播放器界面、弹幕、字幕、快捷键、清晰度切换和各种原生功能全部继续使用 B 站自己的，插件只接管底层的视频与音频下载。

如果想要更变态的效果可以选择0.8.9.2 这是最后一个替换原本播放器的版本 可能在某些时候0.8.X 版本加载会更流畅

本项目是非官方、实验性质的开源扩展。它不会绕过会员、登录、区域、清晰度、审核状态、数字版权保护或媒体签名限制。

安装

有两种方式安装，对于Chrome内核的比如Chrome,Edge,Opera 等浏览器可以优先尝试插件版，这版通过了多次测试，实测效果比油猴版会更好一些。对于Firefox，Safari浏览器的用户可以尝试实验性的油猴脚本，搭配Tampermonkey插件使用，优点是可以自动检测更新，并且跨平台。

方式1 插件安装

1. 在项目发布页下载最新的扩展压缩包；
2. 将压缩包完整解压到固定目录，不要直接在压缩包里打开；
3. 在 Chrome 地址栏输入 chrome://extensions；
4. 打开右上角的“开发者模式”；
5. 点击“加载已解压的扩展程序”；
6. 选择解压后的扩展目录，该目录中应直接包含 manifest.json；
7. 刷新已经打开的哔哩哔哩视频页面。

方式2 油猴脚本安装

1. 装 Tampermonkey
2. 点这里：安装线程撕裂者
3. 打开 B 站视频，完事

• 有新版会自动更新
• 设置在播放器 ⚙ → 更多播放设置
• Chrome / Edge 没反应：扩展管理 → Tampermonkey → 详情 → 打开“允许用户脚本”（老版本是打开“开发者模式”）

从源码安装

克隆或下载源码后，可以直接在扩展管理页面选择项目根目录。

更新版本时，请在扩展管理页面点击“重新加载”，然后刷新视频页面。若旧版目录已经移动或删除，可以先移除旧版，再加载新版目录。

建议设置

下面是推荐设置，只是参考，每个人的网络差别很大，最后以你自己看着顺不顺为准：

• CDN 模式：大陆 CDN
• 并发线程：推荐 8 到 32，默认是 8

一般先用 8，缓冲跟不上再试 16 或 32。线程不是越多越快，线程越多，连接、加密、调度和重组的开销也越大。128 更适合排查特殊线路，不建议一直开着。

设置入口在 B 站播放器右下角的齿轮菜单里。点击扩展图标可以打开侧边栏，查看目前总线程、总速度和每条线程实际连接的节点。

原理解释

它到底是怎么加速的

B 站的 DASH 视频通常把画面和声音分开传输。线程撕裂者会读取当前账号已经拿到的播放清单，解析视频和音频的分段索引，然后把播放器要读取的字节范围继续切小，多路同时下载。

B 站原生播放器
        ↓
播放器需要一个媒体分段
        ↓
线程撕裂者把分段切成多个 Range
   ↙       ↓       ↓       ↘
线程 1   线程 2   线程 3   线程 4 ……
   ↘       ↓       ↓       ↙
校验字节位置并按原顺序组合
        ↓
交回 B 站原生播放器继续播放

这不是把同一个文件重复下载几十遍。每条线程负责不同的字节范围，任何一块返回的位置、长度或者文件总大小不对，都会被拒绝，不能直接塞进播放器。

大陆 CDN 模式会优先使用可以正常读取当前视频的大陆节点；海外 CDN 模式则优先使用海外线路。只要节点能正确返回对应的 Range，它就是可用路线。慢请求还可以切换路线重试，不必让整段视频一直等一条卡死的连接。

为什么“大陆 CDN + 多线程”能缓解海外冷门视频卡顿

先别把这个当成玄学换节点。Bilibili 官方在 《B站公网架构实践及演进》 中介绍过自己的视频数据分发架构。这篇文章由“哔哩哔哩技术”发布，作者是 B 站系统部网络团队。下面这张图就是官方说明中的原文截图：

官方给出的架构很直白：

• CDN/边缘节点规模较小，算力和存储有限，主要缓存热门数据；
• 区域级骨干节点容量更大，承担边缘节点的容量溢出、故障备份和二级缓存；
• 核心 IDC 是源站，保存 B 站的全部服务资源。

这就能解释一个很常见的现象：海外热门视频很快，冷门视频却慢得离谱。

热门视频：海外边缘节点命中缓存 → 就近读取 → 很快

冷门视频：海外边缘节点没有缓存
        → 向区域节点或核心 IDC 回源
        → 路径更长、延迟更高、单连接更容易卡住

上面“海外冷门视频更容易发生远距离回源”是根据 Bilibili 官方分层架构作出的解释，不代表每个视频、每个运营商、每个时间段都会走完全相同的线路。但是它至少说明了一件事：海外边缘节点本来就不可能缓存所有视频，越冷门的资源越不能只赌就近节点。

线程撕裂者的大陆 CDN 模式，目标不是让地理距离凭空变短，而是尽量改用能够直接、正确返回当前媒体 Range 的大陆节点，降低一直困在海外冷缓存边缘节点上的概率。大陆节点距离海外用户更远，单连接可能照样很慢，所以只切大陆 CDN 还不够，必须再配合真实多线程：

大陆 CDN：解决“去哪里拿到冷数据”
多线程：  解决“单条连接拉不满、某个 Range 卡住”

两者组合：从可用路线拿数据，再用多个独立 Range 聚合吞吐

例如同一个媒体分段被拆成 32 个不同的字节范围后，32 条请求可以同时在途。某一条连接延迟高，不代表其他字节块必须跟着干等；某条路线卡住，也可以换其他可用路线重试。这就是“大陆 CDN + 多线程”的意义：大陆 CDN 提高冷数据可用的概率，多线程尽量把高延迟路线上的可用带宽真正吃满。

它仍然不能创造不存在的国际带宽。如果所有可用节点最终都堵在同一个出口，提升就会有限。但如果问题来自海外边缘节点冷缓存、单连接吞吐低或者部分 Range 偶发卡死，这套组合就是对症的。

为什么传统 CDN 插件解决不了所有冷门视频

普通 CDN 优选通常是：

测试几个节点 → 选一个最快的 → 继续单路下载

如果问题只是 B 站选错节点，这种方法当然有效。但是冷门视频经常不是单纯的“节点选错”，而是单条连接速度低、某些 Range 卡住或者不同文件位置表现完全不一样。换完节点仍然只有一条下载连接，所以还是会卡。

线程撕裂者解决的是另一个问题：不只换路线，还真的把媒体 Range 拆开并发下载。只要瓶颈来自单连接、单节点或者某些请求偶发卡住，多线程就有机会把总吞吐拉起来。

它也不是魔法。如果你的宽带本身不够，或者所有 CDN 最后都堵在同一个国际出口，开到 128 线程也不能凭空创造带宽。

怎么知道插件到底有没有工作

别靠感觉猜，直接看数据：

• 扩展图标在下载时会显示当前在途线程数；
• 侧边栏会显示目前总线程和总下载速度；
• 视频线程与音频线程会分开显示；
• 每条线程会显示实际使用的 CDN 主机；
• 播放器右键“视频统计信息”里的节点、速度和分段是插件实际的下载数据，Player Type 一行会写“线程撕裂者 … 接管”；
• 播放器前方的缓存持续增长，说明下载的数据正在正常交给播放器。

线程偶尔显示 0 不一定是坏了。视频暂停、缓存已经足够、一个分段刚好下载完成或者还没拿到播放清单时，本来就可能没有正在传输的请求。

当前版本保留了哪些 B 站功能

0.9.x 使用 B 站原生播放器界面，不再自己重复造一套播放器，所以这些功能继续由 B 站负责：

• 清晰度和编码选择；
• 弹幕显示、发送和弹幕设置；
• 字幕、自动生成字幕和字幕切换；
• 倍速、音量、画中画和全屏；
• 合集、分 P、自动连播和站内切换；
• B 站自己的快捷键与播放器设置。

插件负责的事情只有媒体下载、CDN 路线、并发 Range、缓冲和失败重试。播放器功能归播放器，加速功能归线程撕裂者，少互相干扰。

常见问题

为什么第一次打开视频可能比热门视频原生起播慢一点？

插件要先读取音视频索引、确认可用节点并准备一段连续缓存。这个过程会有额外开销，但是目的是避免高码率视频刚播两秒就开始转圈。

0.9.0.3 修复了热门视频已经播放零点几秒、加速内核完成预缓冲后又回到开头重播的问题。同一视频的接管只允许保持或前进，不再把已经显示过的画面倒回去。

播放视频时，右键统计信息数据很奇怪？

这是正常的，由于接管了播放器的一些东西，导致统计信息异常，我会逐步解决这个问题。

为什么拖动到没有缓存的位置会等一下？

因为跨度很大的跳转不能继续使用旧位置的连续缓存。插件会取消旧位置的任务，从新位置重新建立视频和音频缓冲。已经缓存过的位置可以直接跳，没缓存过的位置必须重新下载。

为什么设置 32 线程却没有一直显示 32？

32 是并发上限，不是要求插件每一秒都塞满 32 条连接。媒体分段较小、缓存足够、请求刚完成或者音视频任务数量变化时，真实线程数都会下降。

为什么 128 线程反而可能更慢？

浏览器、路由器、运营商和 CDN 都不是无限并发。连接太多会增加调度开销，甚至触发节点限制。一般推荐 8 到 32，可以先用默认的 8，不够再加，别把线程数当跑分数字。

为什么有些视频没有 4K 或某种编码？

插件只能使用当前账号、当前视频和 B 站播放清单里已经提供的内容。没有会员权限、视频本身没有对应画质、浏览器不支持对应编码，插件都不会凭空生成。

能不能解除地区、会员或者登录限制？

不能。线程撕裂者只优化你已经有权访问的媒体字节，不负责绕过任何播放权限。

会不会上传 Cookie、播放记录或者视频内容？

不会。插件不提供遥测服务，也不会把视频内容上传到第三方服务器。媒体数据只进入当前页面的内存和浏览器媒体缓冲区。

哪些情况提升会比较明显？

• 海外观看冷门视频、4K 或高码率视频；
• 普通测速很快，但是 B 站单连接速度很低；
• 某些媒体 Range 经常卡住；
• 不同 CDN 到你所在地的线路质量差异很大；
• 原生播放器的下载速度长期低于视频实际码率。

哪些问题它解决不了？

• 你的宽带本身就跑不动当前码率；
• 所有节点共用同一个拥堵出口；
• B 站网页、评论区或者接口本身加载慢；
• 当前账号没有播放权限；
• B 站修改了播放器结构或者媒体接口。

反馈问题

如果你要反馈“还是卡”，最好一起提供这些信息：

• Chrome 版本和插件版本；
• 所在国家或地区以及网络运营商；
• 视频 BV 号、清晰度和编码；
• CDN 模式与线程数；
• 侧边栏里的总速度、线程数和错误信息；
• 是首次加载慢、连续播放卡，还是大幅拖动后卡。

只说一句“没效果”基本没办法判断到底是节点、带宽、编码、权限还是插件出错。请不要公开 Cookie、访问令牌或者完整的媒体签名地址。

开发与构建

项目没有运行时包管理器依赖，Chrome 可以直接加载源码目录。

src/       原生播放器接管、多线程下载、Range 校验和 CDN 选择
popup/     侧边栏与线程速度显示
icons/     扩展图标
scripts/   Windows 构建脚本
user_scripts/ 油猴脚本（自动生成）和它的小适配层
dev/       本地回归测试

Windows PowerShell 构建：

.\scripts\build.ps1

构建结果会写入 dist。扩展签名私钥保存在本地 private 目录，并已被仓库忽略，任何情况下都不要上传。

油猴脚本：改完 src 后运行下面这条，重新生成 user_scripts/bilibili-thread-ripper.user.js，一起提交。

.\scripts\build-userscript.ps1

油猴只看版本号更新，想让大家收到新版，记得先改 manifest.json 里的版本。

开源协议

项目采用 MIT 开源协议。你可以使用、复制、修改和分发，也可以用于商业项目，但必须保留原始版权声明和许可证文本。