豆瓣+圖書館查詢助手實測：看豆瓣書評直接查圖書館館藏

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

同一套瀏覽器擴充功能，掛在三個商店裡是三種命運：在 Chrome 線上應用程式商店，它是 5.0 顆星、741 位使用者、2026 年 9 月還在更新的活工具；在 Edge 附加元件商店，它落後兩個版本但照常運作；到了 Firefox 附加元件商店，它停在 2024 年 5 月的 1.1.8，程式裡寫死的舊網域如今已是網域停放頁，裝了也查不到任何東西。差別只有一處：Firefox 連的後端網址和另外兩家不同。

「豆瓣+圖書館查詢助手」做的事情很單純：你在豆瓣讀書看一本書的書評時，它自動抓頁面上的 ISBN，查出這本書在圖書館的索書號、館藏地點與在館狀態，直接掛在書頁右側欄。查館藏從「另開分頁、重新輸入書名」變成「往下捲一點」。我們拆開三個商店的安裝包讀程式碼，並對它真正的查詢引擎做了六館實測；先講結論：想裝請裝 Chrome 版，Firefox 版現在是死的，而每個版本的生死都繫在同一件事上：開發者自己的那台伺服器。

它把查館藏這一步縫進豆瓣書頁

照官方說明與程式碼，使用流程是：安裝後點工具列圖示，在設定頁勾選要查的圖書館（上限兩館，可以並排比較），之後打開任何一本書的豆瓣頁面，右側欄頂端自動出現館藏卡片，列出館藏位置、索書號、在館或借出、可借數量，連應還日期都看得到。另一條路是反著來：在任何網頁選取書名或 ISBN，右鍵選單直接叫出查書視窗，連豆瓣都不用開。

卡片上的資訊值得拆開看。每一筆館藏條目對應一個實體位置：在哪個館、哪個書庫、索書號是多少、這個位置有幾冊、幾冊可以外借。借出的冊數在館方系統供應時會標示應還日期，這個欄位視館而定，本次實測六館裡只有杭州館回傳了它。把兩個館同時勾起來，兩組卡片並列出現，哪家有書、哪家要等，一眼比完。這個雙館同查並不是一開始就有的功能：官網評價區還留著這段互動，有使用者許願「能支持圖書館多選就好了，省圖和市圖書館可以同時查看」，開發者回覆「新版本已支持圖書館多選」。

設定頁的圖書館清單按省級圖書館、省會城市圖書館、其他城市圖書館分組，可搜尋過濾。這份清單由伺服器動態供應，擴充每六小時重抓一次，離線時退回安裝包內建的名單。卡片右上角有複製鍵，一鍵把館名與館藏明細（地點、索書號、狀態）放進剪貼板，方便轉給要借書的人；卡片尾端還有一個連去 GitHub 專案的品牌連結。把資訊就地釘在閱讀頁側欄、不打斷閱讀本身，這個思路與把章節評論釘在微信讀書側欄的擴充是同一套：閱讀平台走到哪，周邊工具就跟到哪。Chrome 商店頁的相關推薦裡，還能看到標記電影看過的「豆瓣一鍵看過」等同生態的小工具，這個圈子不大，但一直有人在縫。

三個商店，三種命運

把三個商店的安裝包各自下載解包，對照清單如下（截至 2026 年 10 月 23 日）：

Pin

Firefox 版的死因值得展開。它自 2024 年 5 月 23 日後就沒再更新，安裝包裡的 content.js 寫死連向 www.navy81.com，而這個網域現在是網站架設服務商的停放頁，任何查詢都到不了圖書館。開發者其實早就搬了家：新版程式全部改連 navy82.icu，Chrome 與 Edge 版都跟上了，只有 Firefox 商店那份被留在舊址。網際網路檔案館的快照顯示 navy81.com 在 2024 年 11 月之後將近兩年沒有新收錄，2026 年 9 月的快照已經是停放頁。Firefox 商店頁上 2.0 顆星的評分與 29 位使用者，就是這段空窗期的存證。

Pin

唏噓的是它生前並不敷衍。商店頁的版本沿革顯示，2024 年 4 月的 1.1.2 一次新增 15 個省市圖書館，之後 1.1.5 補上首都圖書館、1.1.6 補上河南省與南京市圖書館，最後一版 1.1.8 帶來雙館同查。停在這裡 17 個月，GitHub 儲存庫的 issue 紀錄裡還看得到 2025 年 8 月有人回報「用不了了」、12 月有人回報「一直顯示正在查詢」，兩件事後來都結案了；但 Firefox 商店自 2024 年 5 月後一版都沒有再出過，這些修復與商店裡那份無關。

Edge 版沒死但慢半拍。它的版本停在 1.3.0（版本讀自商店實際下載的安裝包；商店頁的更新日期為動態載入，靜態頁面讀不到），錯過的是 8 月底到 9 月初的兩輪更新：8 月 31 日的 v1.4.0 給設定頁加上圖書館搜尋、只看已選、恢復預設與線上更新清單；9 月 4 日的 v1.5.0 補上更完整的館名離線清單、六小時本地快取與增量校驗。同一個開發者，三個上架管道，維護力道差這麼多，這本身就是小型開源專案常見的縮影：清單上的數字還掛著，實際活躍度早已分流，我們體檢開源 iOS App 清單時看過同樣的落差。

引擎不在你的瀏覽器裡

把 Chrome 版安裝包解開，manifest 裡對外連線的白名單只有一條：navy82.icu。也就是說，擴充從頭到尾沒有直接連任何一家圖書館，它把 ISBN 加上館代碼丟給開發者的伺服器，由伺服器代查各館的館藏系統再把結果送回來。擴充是遙控器，引擎在別人家。

分工攤開來看更清楚。擴充在本機只做三件事：讀豆瓣書頁的資訊區塊抽出 ISBN、把查詢送去 navy82.icu、把回傳的 JSON 畫成卡片。其餘全部在伺服器端：一百零一家圖書館用的檢索系統至少有 LibSP、ILAS、匯文 OPAC、SirsiDynix 幾種，查詢語法、回傳格式、館藏狀態的判讀，每一館都要單獨適配。2026 年 9 月 5 日的服務端更新就是一例：修復鄭州圖書館的舊檢索系統逾時（改接它官網現用的 SirsiDynix 服務），一併修好泉州、南通、徐州、鹽城、嘉興等九館的查詢，並對十館做完並發回歸。這也解釋了體積：擴充安裝包只有 69.36 KiB，因為引擎邏輯一行都不在裡面；同一位開發者的 Windows 桌面版則有 74.3 MB，是另一種把東西全打包進來的做法。這個架構對使用者的紅利在同一次更新看得很明白：桌面版與擴充都不必重裝，重新連線就吃到修復，README 裡也明寫「圖書館維護只需更新服務端」。

入口也在別人家：content.js 抓的是豆瓣頁面的資訊區塊與右側欄這兩個 DOM 位置，豆瓣哪天大改版，卡片就會從書頁上消失。所以這類擴充其實有兩個單點，開發者的伺服器與豆瓣自己的頁面結構，Firefox 版死於前者，後者至今沒出過事。

這個架構同時決定了兩件事。

資料流方面，你查的每一本書，開發者伺服器都看得到。而且 content.js 的設計是進入任何一個豆瓣書頁就自動執行，抽出 ISBN、立刻發查詢；設定頁只有選圖書館的選項，沒有關閉自動查詢的開關。裝了它逛豆瓣，書目瀏覽紀錄等於持續送往同一台伺服器，想停只能整個移除。請求內容本身倒是節制：每次送出帶的是 ISBN、館代碼、擴充版本號與兩個標示介面版本的固定欄位，沒有帳號資訊，跨網域請求在瀏覽器預設下也不會附帶你在豆瓣的 cookie；真正的曝光面是查詢行為本身，你看了哪些書、何時看的。這與我們實測開源 Cookie 管理器 Best Cookier 時收斂到的原則同一條：判斷工具的隱私邊界，要看資料實際流向哪裡，不是看它宣稱存在本機的項目。

權限面倒是乾淨：整個擴充只申請 storage 與 contextMenus（右鍵選單）兩項權限，沒有讀取所有網頁內容的廣泛授權；商店頁的隱私宣告也只登錄「網站內容」一項，並聲明不用於無關用途、不出售第三方，屬開發者自述，與程式碼可見的行為相符。

穩定性方面，這類工具的生死不在商店頁，在後端那台伺服器。Firefox 版的死因正是後端搬家沒跟上；反過來說，只要 navy82.icu 活著一天，Chrome 與 Edge 版就能用一天。評估任何倚賴第三方後端的擴充功能，先看引擎住在誰家。

六館實測：五館回真實館藏，國家圖書館白等 30 秒

六館實測直接打後端介面，繞過介面層測的是引擎本身。以《三體》的 ISBN 9787536692930 向六個圖書館代碼查詢（2026 年 10 月 23 日實測）：

結果兩極。五個館回來的是真館藏：上海圖書館一口氣回 552 筆，第一筆是淮海路館基藏書庫的《三體：地球往事三部曲之一》，索書號 I247.55/0487，重慶出版社版本，狀態在館、可外借。552 筆指的是館藏條目數，同一本書的不同版本、不同書庫各算一筆，回傳資料裡光淮海路館基藏書庫就有多筆。同一查詢再發一次，3 秒出頭就回完，伺服器對每筆查詢快取三分鐘，第二次看同一本書就快了。

首都圖書館那輪還測出一個值得記下的行為：第一次查回 0 筆，等了 24.7 秒；隔幾秒重發，224 筆 6.3 秒回來。後端對單館查詢有間歇性失敗，遇到查無資料先重試一次再下結論，是使用這類工具的基本動作。

中國國家圖書館那條線實測等於不可用：《三體》等 31.3 秒回 0 筆，換《活著》再測，31.8 秒同樣 0 筆。國家圖書館不可能沒有這兩本書，合理的解釋是它的館藏系統對代查介面設了門檻或擋掉了請求，實際原因伺服器端沒有說明。想在設定頁勾國圖的人，要有等 30 秒然後看到空結果的心理準備。

冷查詢的耐性也要有。上海館冷查詢這輪跑了 59.9 秒，遠超擴充自己設的 20 秒逾時上限，這種情況下介面只會顯示查無此書，其實只是還沒回來。另外兩個設計細節：後端也接受直接用書名查詢，會自動解析成 ISBN 再查；查一個不存在的 ISBN 不會報錯，安靜回空結果。

開發者把每週用量攤在官網上

現在的官方網站 navy82.icu 本身就是一頁完整的產品說明書，比較難得的是它公開自己的用量：官網每週一更新上週統計，只秀聚合數字、不公開個別 IP。2026 年 10 月 12 日至 18 日那一週，這個服務總共被查詢 1,472 次，其中中國大陸境內 1,056 次、境外 408 次，一共動用了 29 家圖書館的介面，館藏查詢合計 1,502 次。兩個數字有個小縫：境內加境外是 1,464 次，比總數少 8 次，統計頁沒有交代這 8 次的歸類。統計把兩個查詢端點分開列，一個 1,016 次、一個 456 次，加起來恰好是總查詢數。

Pin

被查最多的是黑龍江省圖書館：679 次，領先所有一線城市大館，占全部館藏查詢 1,502 次的將近一半。原因寫在程式碼裡，它是圖書館清單的第一項，沒有設定過的使用者預設就查它。這個排行榜反映的是預設值的副作用，不是哪個館特別熱門。排行第二梯隊的數字反而更像真實需求：首都圖書館 246 次、廣州圖書館 151 次、湖北省圖書館 48 次；上海圖書館館藏最豐（本次實測 552 筆），一週卻只被查 14 次。耐人尋味的是中國國家圖書館：被查了 196 次，對照本文兩本書實測皆 0 筆的結果，這 196 次查詢換到的體驗值得打上問號。

訪客所在城市的排行則是另一個故事：北京 292 次、杭州 191 次、廣州 148 次、長沙 146 次，上海 54 次。境外查詢占近三成，表示海外有一群人在用：往返兩岸的人、研究中國出版品的讀者，或單純想查對岸館藏的人。一個只覆蓋中國大陸圖書館的工具，有超過四分之一的查詢來自境外，這個數字本身就是需求的註腳。

順帶一提數字口徑：官網首頁的行銷文案說全國 60+ 家省市級圖書館，GitHub 的 README 寫 90+ 家，伺服器實際回傳的清單是 101 家。三個數字指向同一份名單，行銷文案落後得最多。工具圈常見的是高報，這裡是少見的低報，實際能查的館比宣稱的多。

適用邊界：101 家圖書館全在中國大陸

名單裡的 101 家圖書館全數在中國大陸：從黑龍江省圖書館到海南省圖書館，省級館、省會城市館到蘇州、泉州這類城市館都有，沒有任何一家台灣、香港或澳門的圖書館。豆瓣讀書本身在台灣可以直接開啟（本文從台灣連線實測《三體》書頁正常載入，資訊區塊裡就印著 ISBN 9787536692930，擴充抓的正是這個欄位），所以這個擴充的意義取決於你借書的地點：如果你往返兩岸、在中國大陸的城市生活或求學，它把當地圖書館變成隨身的書庫查詢台；如果你的借書範圍只在台灣，這套做法參考價值有，館藏查詢本身用不上。

兩個名詞順便說清楚：索書號是書在圖書館書架上的門牌號碼，抄下來到館就能按號找書；在館與借出對應可借與已被借走。搞懂這兩個詞，卡片上的資訊就全部可讀。

桌面版與 GitHub 專案：活著，但沒有授權條款

這個專案不止擴充。GitHub 上的 douban_library 儲存庫（2024 年 2 月建立，70 顆星、8 個 fork）顯示開發節奏相當密集：2026 年 8 月 28 日到 9 月 5 日一週多內，連發桌面版 2.2.0、2.3.0、服務端修復與擴充 1.4.0、1.5.0。桌面版有 Windows 免安裝執行檔（74.3 MB）與 macOS 版（2.7 MB），直接連後端介面，不安裝擴充也能查書；儲存庫的 release 目錄也放了擴充 1.5.0 的離線安裝包，給進不了商店的環境用。README 提醒 Windows 的 SmartScreen 會警告來源未知，屬安裝時的正常現象。本文沒有執行桌面版，對它的行為不做判斷。

要留意的是授權狀態：儲存庫裡沒有 LICENSE 檔案，2024 年 5 月 29 日有人開 issue 詢問授權，issue 後來被關掉，LICENSE 檔案至今沒有出現。公開在 GitHub 不等於授權你修改或商用，想基於它的程式做東西，得先透過商店頁的信箱問過開發者。GitHub 帳號 wyj0605 與商店頁登錄的開發者信箱指向同一人，擴充、後端、儲存庫是同一雙手在顧。

值不值得裝

裝或不裝可以拆成三個問題：你的借書地點在不在那 101 家館裡；你介不介意逛豆瓣書頁時書目資料自動送往開發者伺服器（沒有關閉開關）；你用的是哪個瀏覽器。三關都過，Chrome 版是個功能真實、開發仍在進行的小工具，一週一千四百多次的實際用量與公開的每週統計，比多數同類擴充透明。Firefox 使用者目前無解，在開發者把新版推上附加元件商店之前，別從商店頁安裝。

放大一點看，這個案例值得記住的地方在於：一個人的伺服器撐起一百零一家圖書館的查詢，同時把它的脆弱攤在明處，後端搬一次家，Firefox 版就再也沒醒過。下次評估任何倚賴第三方後端的工具，先問引擎住在誰家，再問商店頁漂不漂亮。