Best Cookier 開源 Cookie 管理器，先看清 Cookie 去向再裝進瀏覽器

Facebook Line Messenger Telegram

先講結論。Best Cookier 是一套功能真實、原始碼完整公開的 Cookie 管理擴充功能，查詢、修改、刪除、匯入、匯出、監控 JavaScript 寫入 Cookie 的行為都做得到，介面也確實講究。但「Cookie 留在你的瀏覽器裡」和「它什麼都沒送出去」是兩件事：翻開它的原始碼，每一次匯出、刪除、換主題的動作，都會帶著一組固定識別碼送到 Google Analytics，而 Chrome 線上應用程式商店頁面上的隱私聲明，寫的是「開發者聲明不會收集或使用你的資料」。

這段落差是判斷要不要裝它的核心。這些判斷不需要安裝也能驗：它的原始碼、商店頁面與問題區全數公開，關鍵說法都對得到原文。

它動的是瀏覽器最深一層的 Cookie 權限

網頁上的 JavaScript 讀 Cookie 有一道牆：被標了 HttpOnly 的 Cookie，指令碼看不到，這是瀏覽器給登入憑證的基本保護。擴充功能走的是另一條路，拿到 cookies 權限後直接呼叫瀏覽器內部 API，HttpOnly 也讀得到、改得了。Best Cookier 的整個介面就建立在這個權限上。

所以它看起來像一個精緻的表格工具，實際上是一把萬用鑰匙的握柄。功能面它做得相當完整：可以用名稱、值、網域、路徑當條件搜尋，一個根網域底下所有子網域的 Cookie 能一次撈出來；可以把特定 Cookie「關注」置頂；能批次處理、開全螢幕模式、開無痕視窗（宣告為 split 模式）；複製時可選 JSON 或請求頭字串兩種格式。介面提供 32 種主題色與漸層背景，這在一票走工程師審美的工具裡確實少見。

Best Cookier 全螢幕管理介面，表格列出 Cookie 名稱、值、網域與到期日等欄位 — Best Cookier 的全螢幕管理介面（官方功能截圖）

要先說清楚一件事：Chrome 內建的開發者工具，在 Application 面板裡其實也看得到 HttpOnly Cookie。這套工具的價值不在「看得到」，而在把「看」變成「管理」，可以直接在表格裡改、可以批次刪、可以把整包狀態打包帶走。最後那一項，就是下一節的風險來源。

帳號共用是官方設計，代價是把登入鑰匙交出去

帳號共用是官方明說的用途。README 的「小竅門」段寫的是：兩個人的瀏覽器都裝上這個擴充功能，就能共用知乎、愛奇藝、GitHub 這類網站的登入，作者同時提醒要注意帳號安全。商店頁的描述則把做法講得更白，把匯出的檔案或複製的內容發給你信任的人。也就是說帳號共用是功能，不是漏洞。

風險在於匯出檔的內容。它的匯出是把瀏覽器 API 回傳的完整 Cookie 物件寫成 JSON，包含那些 JavaScript 平時碰不到的 HttpOnly 登入憑證。這種檔案實質上就是帳號鑰匙，誰拿到檔案，誰就能在另一台機器上把你登入。傳出去的那一刻，你的帳號安全就取決於對方和那條傳輸路徑，而不少網站的服務條款並不允許帳號移交，被網站偵測到異常登入時，鎖號的代價也是你自己承擔。

如果你要研究的是「把 Cookie 傳給別人」這整件事的加密與落地風險，可以再看另一篇對開源 Cookie 分享工具的拆解，那篇把傳輸加密與明文落地的落差攤得更開：Cookie-share 開源 Cookie 分享工具。

Cookie 留在本機，操作紀錄卻沒有

這是整個評估裡最值得停下來的一段。原始碼 utils.ts 裡有一個負責上報的函式，用的是 Google Analytics 的 Measurement 協定：它會在瀏覽器的本機儲存區產生一組 UUID 當固定的 client_id，之後每次觸發都把事件名稱加上時間戳送去 google-analytics.com。觸發點藏在幾乎每個按鈕後面，匯出、匯入、刪除、進設定、開全螢幕、開關監控、複製成 JSON、複製成請求頭、換主題、換背景、打開網域篩選，超過十五個動作，而介面上沒有「關閉資料回報」的開關。

把它攤成三層會更公道。最裡層是 Cookie 值本身，確實沒有出門，上報的事件裡不含任何 Cookie 內容，作者在 2024 年 6 月回答使用者提問時說的「Cookie 都在插件內部管理，在你瀏覽器本地存儲」，就這半句而言成立。往上一層是行為：誰在什麼時間做了什麼操作，帶著一組可以長期關聯的識別碼，進了 Google 的伺服器。最外層是聲明，商店頁寫的是開發者聲明不會收集或使用你的資料，對照中間這層的事實，你只能自己決定把「操作事件算不算資料」這題判給哪邊。

有個工程細節把出路也一併指明了：上報用的 measurement_id 和 api_secret 是編譯時才注入的環境變數，公開倉庫裡沒有這組值。照原始碼自己編譯的版本沒有那組憑證，遙測實際上失效：請求就算發出，Google 端也不會記錄任何事件。換句話說，作者在 README 建議大家 fork 之後自己編譯安裝，那不只是一句場面話，也是拔掉這條回報線的實際方法。

另一個把「成品留在本機」寫進說明的例子是：Gofullpage 整頁截圖擴充功能。

開了監控之後，Reddit 壞了半年

它的監控功能對前端開發者有實際用處：在網頁載入前注入一段程式，把 Document 物件上 cookie 屬性的寫入動作包一層，之後任何 JavaScript 寫 Cookie，都會在控制台印出新增、修改或刪除的日誌。這個手法沿自另一個開源專案 js-cookie-monitor-debugger-hook，作者在鳴謝段有明寫。

Best Cookier 監控功能在瀏覽器控制台輸出 Cookie 新增、修改與刪除的日誌 — 監控功能會在控制台印出 JavaScript 寫入 Cookie 的動作（官方功能截圖）

問題出在這層包裝的寫法，而且有真實受害者。GitHub 問題區 #10 從 2025 年 11 月開始有人回報：只要開著這個擴充功能，Reddit 的登入頁就是一片空白，停用後就恢復正常。接下來幾個月陸續有人附和，有人回報 Reddit 上很多圖片顯示不全，回報一路延續到 2026 年 3 月，問題單裡沒有看到作者回覆。

根因在 2026 年 4 月 11 日的修復提交裡看得很清楚。舊版的包裝直接用 defineProperty 覆寫 cookie 屬性，而且只寫了新的 setter，沒有把原本的 getter 帶過去，結果屬性變成只能寫不能讀，網頁裡任何讀 document.cookie 的程式拿到的都是 undefined。像 Reddit 這種在啟動階段就讀 Cookie 的網站，等於一開機就斷腿。修復版改成先取得原始的屬性描述器、getter 與 setter 都原樣保留，只在中間插一次記錄，還順手補上了這個專案的第一批單元測試。商店版三天後跟著更新到 2.4.2。

有個使用細節要知道：監控的開關狀態存在每個網站自己的 localStorage 裡，開過一次就持續生效，直到你按結束監控。所以如果某個網站突然壞掉，把監控關掉或直接停用擴充功能再測一次，是成本最低的排查動作。這類在所有網站注入程式的功能，相容性本來就是它的宿命，原始碼裡還留著一條註解，記錄更早之前和騰訊影片網站之間的衝突修復。

一個 Cookie 工具，為什麼能停用你的其他擴充功能

看安裝權限清單會發現它拿的不只是 cookies：還有 tabs、scripting、storage、notifications，以及一個在 Cookie 工具裡很少見的 management，再加上涵蓋所有 http 與 https 網站的主機權限。

management 權限對應的是「Cookie 安全衛士」功能。你可以指定某幾個網站，例如網銀或交易所，再指定幾個你信不過的擴充功能；之後每次你打開這些網站，它就把名單裡的擴充功能停用，跳出通知說「將禁用某某擴充功能，以防止 Cookie 被竊取」，離開網站時再恢復。用意正當，場景也真實：README 的聲明段自述，幣圈曾有人因為其他擴充功能竊取 Cookie 損失一百萬美元，事件後有 X 上的博主把該擴充功能定性為惡意擴充功能，作者把這段寫成了一個自嘲的聲明。

但把功能讀完後，權力的形狀要自己看清楚：一個 Cookie 管理工具，能開關你瀏覽器裡的其他擴充功能，而且它監聽著每個分頁的建立、更新、切換與關閉。恢復啟用依賴一份存在本機的狀態表，狀態若因故過期，被停用的擴充功能不一定會自動回來，這種時候要去擴充功能頁手動檢查。作者在聲明段的建議是乾脆的：有疑慮的人，fork 原始碼自己編譯。對一個 MIT 授權、程式碼可讀性也不差的專案來說，這是誠實的建議。

要對照「權限拿得少、隱私工程做滿」的另一種做法，可以看這個例子：EcoPaste 開源剪貼簿工具。

商店版和原始碼之間的差距，只能用信任補

最後一塊拼圖是版本。商店上的版本是 2.4.2，2026 年 4 月 14 日更新；公開倉庫的 package.json 停在 2.4.0，而且這個專案從沒在 GitHub 發過任何一個 release。這不是新鮮事，2024 年 11 月就有使用者在問題區問商店版和原始碼差在哪裡，作者的回答只有四個字：商店圖示。

「差別只在商店圖示」是不是事實，外部無法驗證，這正是閉源二進位檔的本質：你多付的不是錢，是一筆信任支出。對多數工具這無傷大雅，但對一套能看到你所有網站 HttpOnly Cookie 的工具，這筆支出的金額和其他工具不一樣。

專案的形態也該放進判斷。這是個人開發者的作品，作者署名 shisongyan（GitHub 帳號 Dolov），MIT 授權，301 顆星、25 個 fork。提交歷史集中在 2024 年 5 到 6 月，兩個月內 91 次提交把主體功能寫完，之後轉為低頻維護，最後一次提交就是 2026 年 4 月修 Reddit 那次。商店端約 1,000 位使用者，5.0 顆星但只有 7 則評分，開發者登記為非交易者，沒有獨立的隱私政策頁面。介面語言只有簡體中文和英文，沒有繁體中文，台灣使用者裝起來會看到英文或簡中介面。

Best Cookier 的 GitHub 專案頁，顯示星星數與 fork 數等專案資訊 — Best Cookier 的 GitHub 專案頁（TechMoon 截圖）

三種人，三條安裝路線

需要臨時觀察 Cookie 變化的前端開發者，直接裝商店版是合理的，監控用完就關，遇到網站異常時先停用它再排查一次。它的監控日誌對學習網站的登入流程確實省事。

要長期管理多組帳號、會用到匯入匯出的人，建議走原始碼自建這條路。環境需求是 Node 加 pnpm，框架是 Plasmo，安裝相依、打包、載入未打包擴充功能三個步驟就能跑完，門檻不高。自建版同時解決兩件事：遙測失效，二進位與原始碼之間的信任差距也跟著消失。

對權限敏感、只是偶爾想看看 Cookie 的人，答案是不裝。開發者工具的 Application 面板能看能刪，不需要把所有網站的 Cookie 權限交給任何第三方。真的有批次編輯或轉移需求時再回來考慮，而且那個時候更該選自建版。把任何工具放進自己的信任根之前，先看清它拿走了什麼，這句話對 Cookie 工具是字面意義的。這種先把敏感內容處理過、再決定交給誰的思路，和把資料丟給 AI 前先在本機脫敏是同一件事，可以參考 Privacy Filter 瀏覽器本地脫敏工具。