一句话简介：
通过在拉取B站首页时，禁止浏览器向上游推荐接口传递 Cookie，从而强制让推荐算法按照 未登录的新访客，遵循热度算法（而不是个性化推荐算法）返回首页推荐。
技术原理
B 站首页的推荐流是通过前端异步请求后端接口拉取数据的（核心接口为 api.bilibili.com/x/web-interface/wbi/index/top/feed/rcmd 等）。
TabulaBili 利用 Chrome 扩展 Manifest V3 的 declarativeNetRequest (DNR) 机制，在浏览器底层网络层进行“外科手术式”的请求头清洗：
[浏览器 B 站首页发起推荐请求]
│
▼
[TabulaBili 扩展底层拦截 (DNR)] ──> 自动剥离请求头中的 Cookie )
│
▼
[B 站后端推荐算法服务器] ──────────> 识别为“全新匿名访客”，默认返回热门推荐
│
▼
[你的浏览器首页] ─────────────────> 无个性化痕迹的纯净推荐流
- 拦截规则仅针对首页 feed 接口生效。当你点击进入视频播放页 (
/video/) 或用户中心时，视频流请求 (playurl) 及其他所有 API 均不受拦截，正常携带 Cookie，因此画质与账号特权丝毫不受影响。 - 看到作者博客里的推荐，我就去用了一下，确实是个很有趣的项目，并且对于拒绝大数据下变成信息茧房的个性化推荐有点效果，使用中发现了原项目几点小问题，就 Fork 后改了一下，下边文章里提供的是我修改后的版本。
扩展截图（请自行忽略样式修改 
）
安装与使用指南
1. 在线安装
访问 Chrome扩展商店 像正常的扩展那样安装就行。
2. 本地安装 (开发者模式)
- 下载扩展：GitHub | 蓝奏云(密码:tjsky)
- 将
TabulaBili-Plus文件夹解压到一个你喜欢的位置。 - 打开 Chrome 浏览器，在地址栏输入
chrome://extensions/进入扩展管理页面。 - 开启页面右上角的 “开发者模式” (Developer mode)。
- 点击左上角的 “加载已解压的扩展程序” (Load unpacked)，选择本扩展所在的目录（即
TabulaBili-v*.*.*文件夹）。
2. 使用方法
- 在浏览器右上角的扩展工具栏中找到 TabulaBili-Plus 并将其固定（Pin）。
2.点击扩展图标打开设置面板：
- 纯净模式：完全阻止个人数据回传，彻底屏蔽个性化推荐。
- 探索模式：前10个内容遵循个性化推荐，以此为起点浏览热门内容。
- 混合模式：扩展间歇工作，交替请求热门与个性化内容，兼顾打破信息茧房和个人喜好舒适圈。
- 个性模式：扩展不做干预，首页推荐遵循 B 站自身算法。
- 智能刷新：在切换开关时，如果扩展检测到你当前正在浏览 B 站页面，会自动帮你重载页面以让新模式立即生效。
- 刷新设备指纹：探索模式与混合模式下，可点击右下角「刷新设备指纹」按钮，强制更新设备指纹。
常见问题 (FAQ)
Q1：看久了之后，还会受算法影响吗？
纯净模式下完全不会。 因为扩展在底层移除了推荐接口的整个 Cookie 请求头，无论你在浏览器本地看多久、存了多少追踪指纹，后端推荐算法在处理 feed 请求时都无法读取。此时对算法而言，你每一次刷新首页，都是一次“失忆”式的全新访问。
Q2：会影响我的历史播放记录和点赞收藏吗？
没有任何影响。 扩展只处理首页推荐流的请求，你在播放页的观看进度、一键三连、稍后再看等行为都会正常保存在你的 B 站账号下。
Q3：抹除整个/部分 cookies 是否有什么隐患？
具体看你用什么模式:
- 「纯净模式」：扩展抹除所有的 cookies 导致B站容易将你识别为爬虫，从而在1~24小时内都返回固定内容。（表现为，关掉浏览器马上再打开 B 站，首页前 10 个视频一模一样）。如果你觉得过于蛋疼，请切换到「探索模式」
- 「混合/探索模式」：扩展会过滤 cookies ，只传递必要的
buvid3和buvid4参数，目前 B 站没有基于 Cookie 的防火墙，也未做参数交叉动态校验，所以目前没有任何问题，但不排除未来哪一天 B 站突然丧心病狂地升级了安全策略的可能性。 - 「个性模式」：扩展不做任何干预，纯原生状态。
Q4：在探索模式/混合模式下，「刷新设备指纹」按钮是干什么的？
在这个模式下，需要给B站必要的两个设备追踪参数buvid3/4（设备特征码）来让B站接口知道你是谁，不重复推送已经给过你的内容。B站此时不知道你的账号，但会利用你的设备指纹识追踪你，刷久了就变成基于设备识别的个性化推荐了。所以扩展设计了「刷新设备指纹」按钮，当你点击时扩展会强制 B 站重新向其后端申请一套全新的的设备指纹，从而切断基于设备识别的个性化推荐。
Q5：为什么采用后端 DNR 和前端 Fetch 混合模式？
为了提高用户体验。 因为 B 站前端有 Wbi 动态签名加密（w_rid 参数）。在探索模式/混合模式下，如果我们只使用 DNR 在网络层去拦截并强制修改 URL 参数（比如加随机数来获取新热门流），会直接破坏哈希校验，导致 B 站后端返回 -403 校验失败。 解法：经逆向发现，B 站的 Wbi 签名只对 URL 的 Query 参数进行哈希验真，并不校验 HTTP 请求头中的 Cookie。因此，扩展利用前端脚本重写 fetch，在请求真正发出的前执行异步阻塞，通知后台 DNR 将规则链（remove/set）编译妥当，随后透传原生 URL，清洗个人痕迹。
Q6：说下TabulaBili和TabulaBili-Plus的区别？
- 原版=PLus版的「纯净模式」
- 优点：超级轻量，本质上是用DNR将请求头擦除了。你甚至可以用uBlock Origin、Header Editor 之类的扩展自己写规则实现效果，连额外扩展都不用装。比如uBlock Origin，只需要一行规则
||api.bilibili.com/x/web-interface/wbi/index/top/feed/rcmd$xhr,removeheader=cookie - 缺点：1、因为B站使用SSR渲染首页，所以前10个视频仍然是个性化推荐。2、前边Q3里解释过，长期完全抹除cookie 有可能被 B 站当成爬虫，只返回固定内容。3、为了同时观看个性化和热门内容需要来回开关扩展，Plus则可以用「混合模式」将热门和个性化内容混合显示。
下载
- TabulaBili-Plus：GitHub | Chrome扩展商店 | 蓝奏云(密码:tjsky) |
- TabulaBili：GitHub
