企业官网建设流程全解析

Bilibili 线程撕裂者（BTR）是一款解决 B 站海外用户看视频卡顿问题的油猴脚本，靠多线程加速下载媒体流。它的 package.json 里没有任何第三方依赖，单元测试只用 Node.js 自带的测试框架就能跑起来，发版只需一条命令。本文带你完整了解 BTR 的测试体系、下载基准测试与自动化发版流程。

一、零依赖：一个npm test搞定全部测试

BTR 的构建和测试刻意做到零依赖——不用 webpack、不用 Jest，甚至不用任何node_modules。整个项目只有三条命令：

node dev/run-tests.js # 或 npm test，跑全部测试 node scripts/build.mjs # 或 npm run build，构建油猴脚本 node scripts/release.mjs # 或 npm run release，发版

测试入口 dev/run-tests.js 把测试分成三类，按顺序逐项运行，并显示每项耗时和 PASS/FAIL 结果：

💡 真实视频测试默认跳过，日常回归完全离线；想验证真机播放时才指定一个视频手动开启。

二、单元测试：vm 沙箱 + 假时钟，精确复现每个失败场景

核心下载逻辑分布在 src/range-core.js、src/cdn-resolver.js 和 src/idm-downloader.js 三个文件里。以 dev/shared-core-test.js 为例，它不启动浏览器，而是用 Node 内置的vm模块建一个沙箱，把这三个源文件加载进去，再注入假的Date.now时钟：

• 假时钟：CDN 节点"两次失败就封禁"的退避逻辑依赖真实时间，测试里直接拨快虚拟时间，几毫秒内验证完几秒才能发生的退避；
• 可复现的失败：模拟"发送 0 字节后 503 的死亡节点""发了一半就停的节点""被取消的对冲副本"等场景，逐个断言封禁名单的行为——比如"被取消的对冲副本不算失败"；
• 边界兜底：验证"所有节点都被封禁时，解析器会退回原始地址列表，永远不会无地址可用"。

dev/auto-concurrency-test.js 用同样的沙箱手法测试 8~64 线程的自动调节控制器；dev/optimization-test.js 则覆盖断点续传、按实测速度分配节点等下载优化。全程不下载一个字节，却把核心逻辑翻来覆去验了一遍。

三、浏览器测试：本地测试服务器 + Playwright 无头浏览器

浏览器测试先用 dev/server.js 起一个只监听127.0.0.1:18763的本地服务器，它做三件事：静态托管dev/下的测试页、代理 B 站的playinfo接口、按白名单转发bilivideo/akamaized媒体请求（只放行 B 站官方域名）。

• 回归冒烟测试dev/regression-smoke-test.js：一次驱动 19 个测试页，覆盖导航、清晰度同步、接管失败回退、缓冲区、配额刷新等场景；
• 油猴脚本测试dev/userscript-test.js：现场构建脚本，逐项检查 UserScript 头部——版本号、@match范围、@grant白名单、每个源码文件"出现一次且顺序正确"，再放进 Chromium 里真实运行；
• 通知面板测试dev/notification-smoke-test.js：用一段 mock 代码伪造chrome.storage环境，让通知面板在浏览器环境里也能被完整验证。

四、下载基准测试：模拟网络里对比新旧两版下载内核

海外加速到底有没有变快？靠真机测一次根本说不清。BTR 的 dev/download-benchmark.js 在纯 Node 环境里搭了一个模拟网络，把任意两个版本的下载内核（如当前src/对比上一次提交）放进同一场"考试"：

• 两种网络模型：pool模型模拟 HTTP/2 下多个请求共享同一节点带宽池；cap模型模拟每个请求各自限速、总带宽受限的"被卡"线路。参考 pics/bilibili-official-cdn-architecture.png，B 站 CDN 正是"边缘节点就近服务、多级缓存"的结构，模拟的多节点场景与其对应；
• 10 组场景：均匀节点、快慢节点混布（0.5~8 MB/s）、节点中途停传、高延迟（RTT 400ms）、低带宽单请求限速等，覆盖海外用户常见的网络组合；
• 指标全面：每组场景跑 3 次取中位数，对比总耗时（wall）、有效吞吐（goodput）、浪费比例（waste）、请求数、首段延迟和最差分段延迟，最后输出加速倍数。

上图是作者在自己线路（Superloop，墨尔本）对杜比视界 4K 视频的实测：从 8 线程版本到自动线程版本，下载速度从 27.0 Mbps 一路提升到 43.0 Mbps，远超 20.5 Mbps 的片源码率。

测试中"32 线程"正是设置面板里的并发档位——面板里的每一个选项，背后都有对应的单元测试和基准场景在守护。

五、发版流程：一条命令，测试不过自动回滚

发版脚本 scripts/release.mjs 把整个发布过程自动化成 6 步，任何一步不满足都会直接停止并给出中文提示：

1. 前置检查：工作区无未提交改动、当前在main分支、能拉到远端 tag、本地不落后于远端、CHANGELOG.md 的## [Unreleased]一节有内容；
2. 生成版本号：按墨尔本时区的"日期 + 当天第几次发版"，如2026.10.13.1、2026.10.13.2；
3. 改写 CHANGELOG：在[Unreleased]标题下插入## [版本号] - 日期，把未发布条目归档为本版记录；
4. 构建 + 全量测试：调用 scripts/build.mjs 生成 user_scripts/bilibili-thread-ripper.user.js（源码里的__BTR_VERSION__占位符在此替换为真实版本），然后跑一遍完整测试；任何测试失败，CHANGELOG 和脚本文件自动还原，发版停止；
5. 提交并打 tag：git commit+git tag 版本号；
6. 打印推送命令：脚本故意不自动推送——因为推送到main就等于把新版发给所有用户，最后这一下必须人来确认。

🔒 也就是说：版本号、构建、测试、回滚、打 tag 全部自动完成，唯一手动的是最后的git push。

六、总结：小项目也能有工程级的质量保障

• 零依赖：单元测试只靠 Node 内置的node:test和vm，克隆仓库装个 Node 就能跑；
• 三层测试：单元测试验逻辑（沙箱 + 假时钟）、浏览器测试验真实页面行为（本地服务器 + Playwright）、可选的真实视频测试验端到端播放；
• 基准测试：模拟网络里对比新旧下载内核，10 组场景量化"快了多少、浪费了多少"，防止优化引入回归；
• 发版门禁：版本号自动生成、测试不过自动回滚、推送必须人工确认，一个人维护也能做到发版不翻车。

对想要借鉴的独立开发者来说，这套"零依赖测试 + 模拟环境基准测试 + 脚本化发版"的组合，几乎是一份可以直接抄作业的模板。