技术深度解析
Bilibili Evolved并非一个单一的脚本，而是一个精心设计的插件系统。其核心采用了一种功能注册表模式：每个功能（例如“视频下载器”、“移除广告横幅”、“自定义CSS主题”）都是一个自包含的模块，向中央管理器注册自己。管理器负责处理生命周期事件——页面加载时、导航时（B站采用单页应用架构）以及设置变更时。这种模块化至关重要，因为B站的前端是一个不断变化的目标；脚本必须经受住频繁的A/B测试和完整的重新部署。
该脚本广泛使用MutationObserver来检测DOM变化。例如，当B站动态加载一个新的视频页面时，观察器会触发功能初始化。下载器模块通过钩入B站内部的`fetch`和`XMLHttpRequest`调用来拦截视频流URL，提取原始的`.flv`或`.mp4`片段，然后通过基于Blob的拼接进行重组。这种方法避免了后端代理的需求，使脚本完全在客户端运行。
一个值得注意的工程权衡是性能与便利性之间的平衡。该脚本注入了一个浮动设置面板（一个Vue.js组件），在较旧的机器上可能会占用较多内存。维护者通过延迟加载重型功能来缓解这个问题：下载器仅在用户点击下载按钮时激活，而不是在每个页面加载时激活。尽管如此，基准测试显示，在启用所有40多项功能的情况下，在一台中端笔记本电脑（Intel i5，8GB RAM）上，脚本会使初始页面加载时间增加约120毫秒。
数据表格：Bilibili Evolved功能的性能影响
| 功能集 | 内存使用 (MB) | 导航时CPU时间 (ms) | 新增DOM节点数 |
|---|---|---|---|
| 基础（无功能） | 0 | 0 | 0 |
| 仅视觉调整（5项功能） | 8 | 45 | 12 |
| 仅下载器 | 22 | 90 | 6 |
| 启用所有40+项功能 | 64 | 120 | 48 |
数据解读： 脚本的模块化设计使大多数用户的开销保持在较低水平，但启用所有功能会使内存使用量增加四倍。维护者不预加载所有模块的决定得到了数据的验证——普通用户几乎感受不到影响。
另一个技术亮点是主题引擎。用户可以编写自定义CSS覆盖规则，这些规则作用于B站的类名（这些类名会定期更改）。该脚本包含一个内置的主题编辑器，支持实时预览，社区已在项目的GitHub Wiki上贡献了超过200个主题。主题系统广泛使用CSS自定义属性（变量），允许在不重新加载的情况下进行动态切换。
该项目还与Bilibili的API集成，用于评论历史导出和观看历史统计等功能。这需要处理存储在cookie和本地存储中的身份验证令牌。该脚本不会向任何第三方服务器发送数据——所有处理都在本地完成——这对于注重隐私的用户来说是一个关键的信任信号。
关键人物与案例研究
主要维护者the1812是一位位于中国的匿名开发者。在项目历史中，超过95%的提交由他们单独完成，偶尔有一个由10-15名定期贡献者组成的小团队贡献。该项目的GitHub仓库显示有2,800多次提交和200多个版本，表明其开发周期非常快。The1812的响应速度在社区中堪称传奇：当B站在2025年初推出一个破坏了许多功能的新UI布局时，修复程序在4小时内就被推送了。
与类似工具的比较
| 工具 | 平台 | 星标数 | 功能数 | 更新频率 |
|---|---|---|---|---|
| Bilibili Evolved | 仅限B站 | 29,073 | 40+模块 | 每周以上 |
| Bilibili-helper (已弃用) | 仅限B站 | ~8,000 | 10个模块 | 自2023年起无更新 |
| Tampermonkey (管理器) | 所有网站 | 不适用 | 脚本宿主 | 每月 |
| uBlock Origin | 所有网站 | 40,000+ | 仅广告拦截 | 每月 |
数据解读： Bilibili Evolved在其细分领域占据主导地位，星标数几乎是其最接近的前辈的4倍。项目的积极维护是一个明显的差异化因素——Bilibili-helper在其维护者失去兴趣后被弃用，使用户面临UI损坏的风险。
一个关于社区韧性的案例研究：2024年12月，B站引入了一个新的视频播放器，对流URL使用了专有的DRM封装。Bilibili Evolved的下载器中断了三天。The1812最初尝试逆向工程该DRM，但很快转向了一个变通方案：通过MediaRecorder API捕获渲染后的视频。这降低了质量（没有4K，没有HDR），但恢复了功能。社区反应不一——一些人称赞快速修复，另一些人则批评质量损失。这一事件凸显了客户端抓取固有的脆弱性。
行业影响与市场动态
Bilibili Evolved存在于一个灰色地带，这反映了平台所有者与核心用户之间更广泛的紧张关系。B站作为一家上市公司（纳斯达克：B