bilibili-block-extension：把 Bilibili 封鎖批次化的 Chrome 擴充，權限給得比功能需要多

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

bilibili-block-extension 是一個用 Manifest V3 寫成的 Chrome 擴充功能，把 Bilibili 的帳號封鎖動作批次化：貼上一批個人空間連結，它就逐一幫你按下封鎖或解除封鎖。它呼叫的是 Bilibili 自己的官方關係操作 API，用的是你當下登入的那個 session，並不是什麼外部破解協定，原始碼裡也看不到把資料外傳到第三方伺服器的動作。但在把它載進 Chrome 之前，有三件事值得先看清楚：它要求的 cookies 權限能讀到你全部的 Bilibili cookie（包含標記為 HttpOnly 的登入 session），遠比封鎖功能本身需要的還多；倉庫其實沒有附任何授權檔；而且這是一個一天做完、之後將近九個月沒有再更新過的單人專案。

這個擴充的功能面半小時就能講完，真正值得花篇幅的是你交出了哪些權限、它值不值得那份信任。下面把機制、權限範圍、授權狀態與維護風險分開來看。

Pin

它把封鎖批次化的方式，就是重複呼叫同一條官方 API

封鎖這件事在程式碼裡發生的位置是 content.js，它以 content script 的身份注入到 bilibili.com 的頁面上下文，直接繼承你那個分頁裡的登入狀態。真正執行封鎖的函式先從 document.cookie 拿到一個叫 bili_jct 的值（這是 Bilibili 用來防範跨站請求偽造的 CSRF token），再把一段表單資料 POST 到 https://api.bilibili.com/x/relation/modify，參數 act=5 代表封鎖、act=6 代表解除，請求帶著 credentials: 'include'，於是你的登入 cookie 會跟著一起送出。

這條 API 不是逆向出來的偏門路徑，它就是 Bilibili 網頁在你按下「加入黑名單」按鈕時自己也會呼叫的同一個介面。換句話說，這個擴充並沒有「破解」任何封鎖機制，它做的事很樸素：把一個本來只能單筆點按的官方動作，套上一層迴圈讓它可以批次跑。送出的表單欄位也不難懂：fid 是要封鎖的目標帳號 ID、act 決定封鎖或解除、csrf 放的就是前面拿到的 bili_jct，其餘是 Bilibili 前端自己慣用的統計與來源參數。正因為它走的是你自己的 session 與官方介面，封鎖成功與否完全取決於你的帳號權限、對方帳號狀態與 Bilibili 當下的限流策略，擴充本身沒有、也無法保證每一次都成功。

批次迴圈每跑完一筆封鎖，就停頓 500 毫秒再跑下一筆，註解寫的是「避免頻率限制」。這是一個固定數值，不會依據 Bilibili 回傳的限流訊號自動放慢，所以當你一次貼入數十甚至上百個帳號時，仍有可能在某一輪撞到限流而出現失敗，這時進度面板會逐筆標出成功或失敗，讓你看到哪幾個沒封成。

封鎖只需要一個 token，擴充卻能讀你全部的 cookie

前面的機制帶出一個值得追問的點：整個封鎖流程實際上只需要一個 bili_jct，而 content.js 是從頁面本身就拿得到它的。可是這個擴充在 manifest.json 裡另外要求了 cookies 這個權限，它允許擴充透過 chrome.cookies 讀取瀏覽器裡屬於 bilibili.com 的所有 cookie，包含那些標記為 HttpOnly、平常連 JavaScript 都碰不到的 session cookie。

Pin

先花一段把 HttpOnly 講清楚，因為它是整個權限討論的核心。cookie 是網站放在你瀏覽器裡的小片段狀態，其中用來辨識「你是誰」的 session cookie 最敏感；HttpOnly 是伺服器在設定 cookie 時加的一個標記，意思是這個 cookie 不開放給頁面上的 JavaScript 讀取，用意是就算某個網頁被塞了惡意腳本，腳本也拿不到你的登入憑證。平常這道防線運作得很好，但瀏覽器擴充是另一回事：一個拿到 cookies 權限的擴充可以透過瀏覽器提供的正式介面繞過這道限制，直接讀到包含 HttpOnly 在內的整組 cookie。也就是說，你在網頁上對 HttpOnly 的安心感，並不自動延伸到你安裝的每一個擴充。

popup.js 裡確實有一整套對應的 cookie 管理介面：getAllBilibiliCookies 會把 .bilibili.com 與 bilibili.com 兩種網域的 cookie 合併去重、顯示成一張表格（少數統計類 cookie 會被內建清單濾掉，但登入憑證那類不在其中），欄位包含名稱、值、網域、路徑、是否 HttpOnly、是否 Secure 與 SameSite；還有「複製全部 cookie 到剪貼簿」與「匯出成 JSON 檔」兩個按鈕。更有意思的是 manifest 裡那行擴充描述自己就寫著「讀取並顯示 Bilibili 網站的所有 Cookie 資訊(包括 HttpOnly)」，這幾乎是一段 cookie 管理工具的範本文字，跟封鎖功能沒有直接關係，比較像這個專案是從某個 cookie 編輯器改過來、再把封鎖功能疊上去的痕跡。

先講清楚一件事：它沒有在偷偷外傳（從程式碼看，cookie 資料只在本機讀取與顯示，沒有任何 fetch 把它送往擴充以外的伺服器）。真正的關鍵在「權限範圍大於功能需要」這件事本身。封鎖功能只要 bili_jct，擴充卻具備讀取與匯出你整組 Bilibili session cookie 的能力，那些 cookie 裡包含用來維持登入狀態的敏感憑證。一個會長期掛在瀏覽器裡的擴充，它持有的權限越大、維護越少，你承擔的潛在風險就越大，這與它有沒有「現在」做壞事無關，而是安裝時就該算進去的信任成本。如果你想要同類的清理型擴充概念，可以對照 Chrome 與 Edge 的瘦身清理 或 批次清理 Gmail 的工具，那兩篇處理的也是「把帳號打理乾淨」這類需求，但權限模型完全不同。

順帶把 README「完全在本機運作、不會上傳任何資料」的宣稱讀精確一點。這句話在原始碼層面成立：整個專案對外發出的網路請求只有一種，就是送到 api.bilibili.com 的封鎖與解除封鎖呼叫，沒有任何第三方分析、統計或更新檢查的端點。但「本地」不等於「不與外界通訊」；每一次封鎖，目標帳號的 UID 都會連同你的登入憑證一起送進 Bilibili 的伺服器，這本來就是封鎖這個動作的一部分。所以這個宣稱的正確理解是「不外傳給 Bilibili 以外的第三方」。至於「你的資料全程不出機器」這個標準，任何要操作你帳號的工具都做不到。

README 寫著 MIT，倉庫卻沒有任何授權檔

授權狀態是另一個裝之前要先確認的門。README 的授權段落宣稱這是 MIT License，後面又補上一句僅供學習與個人使用的但書；但實際去倉庫根目錄找，並沒有 LICENSE 檔，GitHub 的授權偵測也回傳 null。沒有授權檔在法律上的預設狀態是「保留所有權利」，並不是自動變成 MIT。

更微妙的是 README 那句話本身就自相矛盾：MIT 授權明確允許商業使用，而「僅學習與個人使用」這個但書卻把商用排除了，兩者擺在一起等於沒講清楚到底能不能拿來做別的事。對只是自己裝來用的讀者影響不大，但如果你想基於它改作、重新分發，或包進自己的產品，這個落差就必須先找原作者釐清，不能直接當成拿到一份可商用 MIT 來用。判斷一個專案真實授權狀態的動作很簡單：別只看 README 寫什麼，去倉庫根目錄看有沒有授權檔、GitHub 回傳的 license 欄位是什麼，後者才是法律上站得住的依據。

一天做成、九個月沒有人再動它

這個倉庫的 created_at 與 pushed_at 都是 2025-11-03，也就是它是在同一天之內建立、推上最後一次 commit，之後就沒有再有任何程式碼更新，距今大約九個月。星標與 fork 數（133 顆星、8 個 fork、0 個開啟中的 issue）顯示它確實有人在用，但「有人在用」不等於「有人在維護」。

這對一個會呼叫第三方平台 API 的擴充是關鍵限制。Bilibili 的內部介面本來就會調整，一旦它改了 relation/modify 這條 API 的參數命名、驗證方式或限流規則，這個沒有後續 commit 的擴充就會直接失效，而且不會有人修。把這點跟前面 cookies 權限擺在一起看，風險組合是：一個持有寬泛 cookie 讀取權限、卻長期無人維護的擴充，長期掛在瀏覽器裡本身就值得三思。它適合當成臨時、用完就停用的工具，不適合當作長期依賴。

固定間隔、預先準備的封鎖名單，以及被誇大的正則過濾

操作面有幾個細節也值得講清楚。批次框的 UID 解析靠的是一個寫死在 popup.js 裡的正則 /space\.bilibili\.com\/(\d+)/g，它只負責從每一行抽出數字 UID，並且會忽略 UID 後面附加的文字，所以你可以在每行連結後面加上自己的註記（例如標明哪幾個是優先處理）而不影響解析。但要留意，這不等於提供「讓你用正則運算式自訂過濾條件」的功能，並沒有一個讓你寫排除規則的欄位，有些介紹把它說成「正則過濾」功能，其實是把這個寬鬆解析講大了。

實際使用還有兩個前提限制。因為封鎖是靠 content script 在頁面上下文裡發出請求，擴充會要求你至少開著一個 bilibili.com 的分頁，沒有就會連不上頁面、操作直接失敗；這也代表它無法在背景獨立運作，關掉所有 Bilibili 分頁它就停擺。另外 README 強烈建議第一次使用時先用「單筆測試」模式封鎖一個帳號、到對方的個人空間確認封鎖真的生效，再跑批次；這個建議背後的原因作者自己也寫了，他無法預測 Bilibili 什麼時候會調整 API，先單筆驗證可以避免批次跑到一半才發現介面已經變了。這是小型個人專案面對大型平台時務實的自保動作，值得照做。

倉庫裡還附了一個 bilibili_black_uids.txt，內含 69 個帳號的個人空間連結，可以直接整批貼進批次框使用。這是作者自己整理出來、他主觀認定值得封鎖的帳號清單，不是任何權威機構核可的名單，也沒有附上每個帳號被列入的理由。要不要照單全收、要不要先抽查幾個再決定，是讀者自己的判斷；把自己不認識的數十個帳號一次封鎖，與封鎖這個動作本身一樣，後果都是你自己承擔。

裝之前的三個判斷

把上面的觀察收斂成三個你可以自己回答的判斷點。cookies 權限的範圍你接不接受，是第一道關：如果只是要批次封鎖，這個權限明顯超過功能需要，你可以選擇不安裝、改用只讀頁面 cookie 的更保守方案，或裝來用完就移除。授權狀態你能不能接受是另一個問題：無授權檔加上 README 自相矛盾的描述，個人自用影響有限，但任何改作或商用前都得先釐清。維護風險則決定你怎麼用它：這是單日建成、九個月未動的專案，加上它依賴的 Bilibili API 隨時會改，把它當短期工具而非長期常駐擴充會更合理。

另外要誠實提醒一條使用協議的灰色地帶。README 的免責聲明自己寫明，這個工具僅供技術學習與個人帳號管理，請勿用於違反 Bilibili 使用者協議的行為，一切後果自負。把封鎖動作批次化、用在自己帳號的適度範圍內，風險通常較低；但如果你打算長時間、高頻率地跑大規模自動化封鎖，就有可能觸碰平台對自動化操作的限制，輕則限流、重則影響帳號，這個風險不在程式碼裡，而在平台怎麼認定你的行為。隱私與過濾類工具的權限與邊界，也可以對照 隱私過濾工具 與 Magic Copy 這類 Chrome 擴充 的討論，看看不同擴充在「能碰什麼」上的取捨。

安裝前自己再核一次三件事的動作不複雜：到 GitHub 倉庫看 license 欄位是不是 null、打開 manifest.json 看 permissions 列了哪些、看最後一次 commit 是什麼時候。這三個動作加起來不到一分鐘，卻足以讓你判斷這個擴充到底碰什麼、誰在維護、能不能拿來改作，比單看 README 的功能亮點可靠得多。