Bilibili 無限歷史記錄擴充功能，把觀看歷史完整存進本地

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

上個月看過一部講資料庫索引的影片，這週想複習，B 站歷史記錄往上滑了十分鐘就是不見蹤影，這種事每個重度使用者都遇過。開發者在 GitHub README 的說法是：B 站官方網頁端只保留最近約三個月的觀看歷史，過了這段期間就找不回來。三個月說長不長，追一整季的教學系列、回頭找激發靈感的素材，都會撞上這道牆。

Bilibili 無限歷史記錄是一款開源瀏覽器擴充功能，解法很直接：你登入 B 站看影片，它在背景把每筆觀看記錄同步進瀏覽器本機的資料庫，數量沒有上限，之後的瀏覽、搜尋、匯出都在本機完成。免費版的資料確實留在你的機器上，這點我翻過它的原始碼逐項核對。但「資料都在本地」是預設狀態，整套服務還留著三條會把資料送出去的路，加上一份比隱私政策所承認的更寬的權限清單，裝之前值得一次看清。

有一個容易誤會的地方先說清楚：它保存的是「記錄」，不是影片本身。每筆記錄的內容照隱私政策所列，是影片標題、封面、UP 主資訊、觀看時間與 BV 號這類詮釋資料；影片仍在 B 站伺服器上，將來哪部影片被作者下架或被平台移除，你手上的記錄會留著，點進去卻是空的。所以它解決的是「找不回看過什麼」，不是「影片永久保存」，後者要靠別的工具。

每分鐘把你剛看的影片寫進本機資料庫

先看運作方式。安裝後擴充功能會掛一個背景 service worker，用瀏覽器鬧鐘每分鐘醒來一次，對 B 站官方的歷史 API（api.bilibili.com/x/web-interface/history/cursor）做增量同步，只補上上次之後的新記錄；第一次使用時按「立即同步」，做的是全量回拉。資料落在瀏覽器的 IndexedDB，並且申請了 unlimitedStorage 權限，避開一般網頁儲存的容量上限。「無限」兩個字的實際意義在此：上限換成你的硬碟空間，服務端不會再把舊記錄擠掉。

備份範圍也不只觀看歷史。README 列出的功能包含收藏夾與「喜歡的音樂」的全量或增量同步；本機端每 24 小時自動產出一份 JSON 備份、預設保留 30 份，手動匯出則有 CSV 與 JSON 兩種格式，CSV 拿去試算表軟體樞紐分析，可以看出自己每個月看哪些主題、花了多少時間，這是官方歷史頁從來不會告訴你的角度。有個設計細節值得點名：刪除墓碑機制。你在本機刪掉的記錄會留下標記，之後從備份還原時，舊資料不會悄悄長回來。介面是卡片式的歷史列表，有分類篩選、日期選擇跟關鍵字搜尋，側邊欄還有收藏夾、聽歌與訂閱合集等入口，官方 README 的示意圖裡累積到七千多筆記錄仍然翻得動。

Pin

本地儲存有個天性要認知：瀏覽器的擴充功能資料跟著設定檔走。換電腦、重灌系統、清理瀏覽器資料或移除擴充功能，IndexedDB 裡的歷史很可能跟著消失，這也是開發者把本機自動備份、JSON 匯出與 WebDAV 同步做成標配的原因。換句話說，「存在本地」的代價是備份責任在你：自動備份目錄設好、偶爾匯出一份 JSON，這套工具的價值才守得住。

增量同步還有個技術上的暗礁，2.2.0 的更新日誌點名修過：B 站的歷史 API 按觀看時間由新到舊分頁返回，如果你回頭重看一部幾個月前的舊片，這筆新觀看會插進清單中間，只記「上次同步到哪個時間」的粗糙做法會把它漏掉。該版改用觀看時間水位加跨頁掃描來補這個縫，同時把「同一部影片在不同時間看算多筆記錄」的計數規則一併整理清楚。這類細節平常看不到，卻直接決定你的備份少不少筆。

本地保存是真的，但它有三條資料出口

先講最關鍵的結論：免費版不上傳。打包後的程式碼裡確實有一個指向 bilibilihistory.com 的 API 客戶端，登入驗證與上傳歷史的端點都在，但那條路對應付費會員的雲端同步；官網隱私政策也明寫，免費用戶的所有觀看歷史資料都存在瀏覽器本地，不上傳任何外部伺服器。換句話說，Chrome 商店描述裡那句所有資料都存在本地，只對不付費、也不開額外功能的使用者成立。

把整套服務的資料流向攤開，其實是一張很短的表：

會員雲端的部分，官網定價頁寫得明白：月費人民幣 9.9 元、年費 99 元（頁面標示原價 12 與 118.8 元），買的是把歷史記錄上傳到開發者伺服器、多設備查看，外加 VIP 群裡的需求優先回應；收藏管理與影片備份列在開發中。伺服器端的資料在帳號有效期間保留，可以隨時要求刪除，這些都寫在隱私政策裡。開發者對收費理由的自述，是涵蓋伺服器與資料庫的基礎設施成本。評估這條路時想想送出去的東西：完整觀看歷史等於一份你的興趣與作息側寫，換到的是換設備不用搬家。

不想付費又需要跨設備的人，它把備份做在你自己的雲端上：支援堅果雲、NextCloud 或 NAS 的 WebDAV，雙向同步加智慧合併，連線憑證加密後存在本機。走這條路，資料落地從開發者的伺服器換成你自己的帳號，信任對象也跟著換成你的雲端服務商。目前有個開著的已知問題：GitHub issue #33 回報，從 WebDAV 還原時可能被瀏覽器的 HTTP 磁碟快取誤導，反覆讀到過期或損壞的備份檔，碰到還原結果異常，先手動清一次快取再試。

Pin

另一條出口是 2026 年 3 月上線的 AI 語意探索，走自帶金鑰路線。你在設定頁填入 OpenAI 相容的端點位址、API 金鑰與模型名稱，預設端點是 OpenAI 官方的 api.openai.com/v1。搜尋時，擴充功能把最近的觀看記錄（預設一千筆）整理成時間、標題、UP 主與影片連結的清單，連同你的問題一起送給那個端點，用自然語言找回只記得大概內容的影片。這條出口的邊界要說清楚：啟用它，等於把你的觀看清單交給你指定的模型服務商，而且那份清單帶著精確到分鐘的時間戳，作息輪廓一併附上；好處是交給誰由你決定，換一家模型商就是換一個端點位址。文件層面還有個落差：官網隱私政策的最後更新日期停在 2025 年 2 月，內容完全沒有觸及 AI 功能的資料流，政策腳步落後於功能現況。

三條出口怎麼選，可以用兩個問題收斂：資料要不要離開你的機器，離開的話交給誰。只想本機保存的人什麼都不用設定；需要跨設備又接受第三方持有，會員雲端最省事，備份與還原都是官方一條龍；需要跨設備但資料只進自己的地盤，WebDAV 多花十分鐘設定，換的是完整的控制權。AI 語意探索與跨設備無關，純粹是搜尋體驗的升級，不開啟也不影響其他功能。

權限清單比隱私政策承認的更寬

它向 Chrome 申請的權限是 unlimitedStorage、storage、tabs、cookies、alarms、declarativeNetRequest，外加 host_permissions 的全網域存取（all URLs）。內容腳本只注入 bilibili 網域的頁面，這部分規規矩矩；但主機權限給的是瀏覽器層級的請求能力，涵蓋所有網站，包含讀取 cookie 的能力。對照官網隱私政策第五節的說法，擴充功能只請求功能必需的最小權限、不請求與核心功能無關的額外權限，兩者之間有明顯落差：從「讀 B 站歷史」這個核心功能出發，全網域主機權限與 cookies 權限都超出最小集合。

公平地說，政策的承諾面寫得不算空泛：不收集 B 站帳號密碼、不碰瀏覽器書籤與其他網站的瀏覽記錄、不收姓名電話這類個人識別資訊、不追蹤跨站行為，雲端資料也可以隨時要求刪除。要留意的點在於承諾與權限是兩套敘事：政策講的是用途，權限清單講的是能力，用途可以被承諾，能力一旦授出去就一直在那裡，兩邊要一起看。

把這份清單翻成白話。storage 與 unlimitedStorage 是把記錄寫進本機，合理；alarms 是每分鐘的定時同步，合理；tabs 讓它讀取分頁資訊；cookies 讓它讀瀏覽器裡的 cookie；declarativeNetRequest 讓它改寫網路請求的標頭；全網域 host permissions 則把後面幾項能力的適用範圍推到所有網站。功能表裡找得出幾個可能的原因：歷史同步本身只碰 bilibili 網域，但 WebDAV 備份要連的是使用者自己填的伺服器，位址不固定，這類功能確實用得到寬的連線範圍。即便如此，隱私政策把權限描述收斂成三條模糊項，沒有解釋全網域與 cookies 的用途，透明度做得比原始碼差一截。

聽起來最敏感的 declarativeNetRequest，實際用途倒是核對得到的。規則檔 referrer.json 裡有八條規則，做的都是同一件事：把符合條件的請求之 referer 與 origin 標頭，改寫成 bilibili 官方網域。比對對象包含 B 站的歷史刪除、空間資訊與搜尋 API 端點，以及 bilivideo.com、akamaized.net 這類影片 CDN 網域。白話講，B 站許多介面會檢查請求來源，得讓擴充功能發出的請求看起來像官方頁面發的，資料才拿得到。這解釋了權限的用途，也劃出能力的邊界：同一套改寫標頭的機制，本質上是請求偽裝工具，目前的規則指向 B 站服務，但能力存在與目前只用於此是兩回事，這正是全網域權限該攤在陽光下看的原因。開源的價值也在這裡：規則檔就放在 repo 裡，任何人都能核對它現在做了什麼。

瀏覽器擴充功能的權限議題，之前介紹會依網站自動切換輸入法的 Input Source Pro 時聊過同樣的判準：權限本身未必是問題，重點是能力與用途能不能被核對。這套擴充功能有原始碼倉庫可以翻、有離線安裝包可以對照，透明度已經高過多數閉源擴充功能；但商店實際推送的是編譯後的產物，日常裝的版本與 GitHub 上的原始碼是否同步，最終仍靠開發者信譽與社群的眼睛把關。技術背景夠的人還有一條路：專案以 WXT 框架開發，倉庫裡拉下來自己建置、裝自己編的版本，連這層不確定性都省了。

免費能用到哪裡，付費買到什麼

免費版拿到的是核心全套：無限同步到本地、收藏夾與音樂備份、搜尋排序、CSV 與 JSON 匯出、WebDAV 備份、AI 語意探索（API 費用自付）。付費購買的是雲端上傳與多設備同步這一段。這種本地免費、雲端收費的結構，對使用者比靜默上傳的模式透明：資料出不出機器，取決於你付費那一刻的決定；安裝時並沒有預先鋪好的傳輸路。

安裝管道除了三家商店，官網還提供離線壓縮包，自己拖進瀏覽器的擴充功能頁就能裝，適合進不了商店或想鎖定版本的人；代價是離線包停留在舊版號，安全修正要自己手動更新。開發者的樣貌也影響信任判斷：這是個人開發者的專案，GitHub 帳號 mundane799699，Chrome 商店上的開發者信箱是 QQ 郵箱，商店標示其未以歐盟貿易者身分登記，支援管道是微信群與 B 站上的示範影片。專案 2025 年 5 月上 GitHub，目前約 130 顆星、14 個 fork，LICENSE 採 MIT。有個小不一致：Firefox 附加元件頁標示的授權是 Apache 2.0，與原始碼倉庫的 MIT 對不上，判斷上以 repo 裡的授權檔為準。

更新很勤，坑也還開著

這專案最不用擔心的是棄坑。Chrome 商店版 v2.2.3 在 2026 年 9 月 15 日剛更新，repo 同月 12 日還有程式碼推送，更新日誌從 2026 年 2 月到 9 月的八個月裡，有六個月推過版號，僅 4 月與 6 月空窗，2.2.0 那一波重做了觀看次數統計與增量同步的邊界判斷。三家商店都找得到：Chrome 約三千位使用者、評分 4.6（十四則評分）；Firefox 版停在 v2.1.4、約兩百位使用者；Edge 版同步上架。

開著的 issue 裡有幾件事安裝前該知道。#35 回報 2.2.0 之後同步期間的 CPU 與網路頻寬消耗大幅增加，尚待處理，對常駐開著瀏覽器的人來說就是風扇會多轉一陣；#33 是前面提過的 WebDAV 快取誤導；#34 則是 Firefox 的容器分頁裡完全不起作用。行為面還有個與 README 行銷文字的出入：說明裡寫在 B 站網頁刪除歷史會同步刪掉本地記錄，但 2.1.0 起這個連動改為預設關閉，官方理由是降低誤刪風險。也就是說，在官方頁面刪記錄時本地副本會留著，想要連動得自己去設定打開。收藏夾的同步則會撞到 B 站的存取風控，2.1.4 版加入了冷卻倒數與斷點續傳來應付。碰到的使用者回饋裡，影片時長與觀看設備的篩選條件仍是開著的功能請求，還沒排進版號。

這個專案與使用者互動的痕跡也看得到。開發者在 B 站放了完整示範影片，更新日誌裡固定維護一份讚賞名單，微信群回來的回饋會直接變成版號裡的修復項目，2.2.2 的更新內容裡甚至有一條就是更新讚賞名單。對個人專案來說，這種把支持者攤在陽光下的做法，比任何空泛承諾都更能判斷健康度。

介面與環境的門檻同樣要列入考慮。介面語言只有簡體中文，商店的語言欄標的就是簡中，功能都看得懂但沒有繁中可用；它吃的是你登入 B 站後的瀏覽器工作階段，帳號要自備；瀏覽器支援 Chrome、Edge 與 Firefox，Safari 沒有版本，蘋果生態的使用者只能透過這三款瀏覽器使用。

誰該裝它，誰再想想

把 B 站當學習資料庫的人，免費版就值得裝。舉個具體情境：你在追一個二十集的後端開發系列，中間穿插看別的影片，三個月後回來找第五集，官方歷史只剩最近的記錄；有這套擴充功能的話，搜標題關鍵字或按日期回溯都找得到，收藏夾也一併備份。資料在本機、能匯出、有自動備份，最壞情況是擴充功能停更，你的 JSON 檔案還在手上。有跨設備需求的人，再從付費雲端與 WebDAV 兩條路裡挑：在乎資料落地就選後者，把觀看記錄放進自己的堅果雲或 NAS。

幾種人可以緩一緩：不願給任何擴充功能全網域權限的；需要繁中介面才用得順的；對 AI 搜尋會把觀看清單送給模型服務商有顧慮的，這個功能不開就不送，但介意的人自然會想遠一點。

想試的話，入門動線很短：登入 B 站網頁版，從 Chrome 商店安裝擴充功能，點工具列圖示按下「立即同步」做第一次全量回拉，之後就交給每分鐘的自動增量。裝完建議繞去設定頁看一遍同步與備份選項，把本機備份目錄設好。同個平台的其他困擾也有現成解法：不想看的推薦內容，可以搭配 Bilibili 按標籤屏蔽影片的腳本；想自動跳過影片裡的業配段落，則有 Bilibili AI Skip 擴充功能 可搭。