微信讀書評論擴充：把其他讀者的章節評論釘在網頁版側欄

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

在別人的地盤上蓋房子，拆遷通知永遠不會提前寄給你。GitHub 上的開源專案 wx-read-comment-extension（微信讀書評論插件）就是這種處境的教科書樣本：它免費、無廣告、MIT 授權，權限清單短到可以一口氣讀完，把微信讀書的章節評論搬進電腦網頁版的側欄；同時它的程式碼停在 2024 年 5 月，2025 年 8 月起有使用者回報評論載入不出來，那則回報開到今天，作者沒有回一個字。

判斷先講：如果你本來就用網頁版微信讀書、螢幕夠寬、想看別人在同一章寫了什麼，它值得一試，因為成本趨近於零；如果你期待的是穩定的工具，或衝著排序、點讚、發表評論而來，這篇會告訴你為什麼要停下來。

它補的是網頁版一直缺的那一塊

微信讀書是騰訊旗下的閱讀服務，手機 App 與電腦網頁版同屬一個服務。評論（官方叫「想法」）存在騰訊的伺服器上：讀同一本書的人可以對某一章留下短評，看別人卡在哪裡、哪一段被劃了最多的線。網頁版閱讀器沒有給這些評論一個順手的位置，作者 my19940202 的動機就一句話：讓網頁版頁面顯示評論，不做孤獨的閱讀者。

側欄長這樣：每則評論顯示頭像、暱稱、發表時間和內容，有人引用原文時可以展開、收合；頂端標示章節名稱與評論總數，旁邊掛著作者的 GitHub 連結和一條「開發不易，求星標支持」的小橫幅。深色模式跟著閱讀器走，夜間閱讀時不刺眼。

Pin

專案 2023 年 11 月開工，兩週後跑通第一版（commit 紀錄寫著：成功構造請求、輸出評論資料）。基本盤面：GitHub 上 155 顆星、6 次 fork、MIT 授權，Chrome 與 Edge 商店都上架；Chrome 版撰寫當下有 928 位使用者、10 則評分，版本 1.1.0，商店更新日期 2025 年 6 月 29 日。

安裝有兩條路。絕大多數人走商店：在 Chrome Web Store 或 Edge Add-ons 搜「微信讀書評論」，一鍵安裝。另一條是手動：作者把打包好的安裝包直接放在 repo 根目錄，檔名就標著打包日期 2024-05-14，下載、解壓縮、到 chrome://extensions/ 開開發人員模式載入。那個檔名裡的日期，就是這份安裝包凍結的時刻。

Pin

權限小到可以整段讀完

Chrome 擴充功能的第一個問題永遠是：它拿了我的什麼。這題的答案我在原始碼裡找過，乾淨得出奇。

manifest（擴充功能的權限宣告檔）只申請一項 webRequest 權限，外加一條只限 weread.qq.com 網域的存取權；內容腳本只注入閱讀頁。評論資料來自微信讀書自家的評論端點，靠你瀏覽器裡已登入的 cookie 取得，工具自己不處理帳號，也沒有後台伺服器。翻遍整個專案，跟微信讀書無關的網路資源只有一個：側欄標題列那張 GitHub 圖示，放在騰訊雲 CloudBase 上，深淺色各一張。沒有統計碼、沒有錯誤回報套件、沒有遙測。

作為對照，同樣是評價不錯的 Chrome 擴充，GoFullPage 曾在商店頁宣稱不收集資料，實際打開 Popup 就送分析封包（細節見我們的 GoFullPage 整頁截圖擴充 一文）。微信讀書評論擴充沒有這類落差：它拿 webRequest 只是為了聽頁面自己的請求（下一節解釋），資料流向單純。白話一點解釋 webRequest 在這裡的用途：瀏覽器裡頁面發出的每個請求，擴充都聽得到網址與參數，但範圍只限 host 權限涵蓋的 weread.qq.com；它聽的目的只有一個，從頁面自己的評論請求裡抄到書號。這跟鍵盤監聽、讀取所有網站內容那類重權限擴充是兩回事，你其他分頁的事它聽不到。

還有個可愛的細節：LICENSE 檔是標準 MIT 條文，版權行卻留著範本原作者 Michael Xieyang Liu 的名字，作者連名字都沒換。這不是安全問題，只是一人 side project 的味道，從授權檔就聞得出來。

三個它自己控制不了的接縫

把原始碼讀完你會發現，這個擴充的每一項功能都架在三條接縫上，而三條接縫的主導權都在騰訊手裡。

書號的接縫。每本書在微信讀書有個 bookId，你以為它從網址解析就錯了：閱讀頁網址裡那段字串，對不上評論端點要的書號，從網址拿不到。作者的第一版做法是從封面圖片網址裡解析，封面圖網址格式不統一、解析失敗率太高，2023 年 12 月改成現在的做法：背景層用 webRequest 監聽頁面自己發出的閱讀與評論請求，從參數裡截取 bookId；內容腳本每 300 毫秒向背景層問一次，等到答案才停止輪詢。這招聰明，也脆弱：哪天頁面不再發那個請求、或參數換了位置，側欄就永遠等不到書號。而且輪詢計時器只在拿到書號時才停，等不到就會一直問下去，不報錯、不通知，就是安靜地空轉。

章節編號的接縫。評論逐章節存放，請求需要 chapterUid。擴充不跟 API 要章節表，而是攤開頁面目錄，數你停在第幾項，套一個寫死的公式：chapterUid 等於索引值加 2。作者在程式碼註解裡自己承認，遇到多層章節的長篇小說這個算法會不準。對應的真實災情：2024 年 2 月就有使用者回報評論的章節和正在讀的章節對不上，那則 issue 開到今天沒有修。讀多卷長篇的人，側欄可能一直在給你隔壁章的評論。

樣式名稱的接縫。深色或淺色模式，靠 body 有沒有 wr_whiteTheme 這個 class 判斷；你切換章節，靠監聽 readerTopBar_title_chapter 這個標題節點的文字變動來重新載入評論。這些名稱都是微信讀書前端的內部命名，官方沒有義務替任何擴充維持。前科確實發生過：2024 年 1 月微信讀書改了一批 class 名稱，作者追著修了一版相容。整個擴充等於把「頁面永遠長得像 2024 年 5 月」寫成了預設假設。

嚴格說它沒有違反什麼規則：呼叫的端點是網頁版自己就在用的，看的是任何人打開瀏覽器開發者工具都看得到的請求，沒有繞權限、沒有破解。只是這種搭便車沒有契約保護，騰訊不需要通知任何人，就能把車開走。

27 次提交講完它的生命週期

這個 repo 從 2023 年 11 月到 2025 年 6 月總共 27 次提交，節奏一目瞭然。2023 年 11 月動工，12 月密集打磨：書號取得效率、日間模式配色、打包流程都那個月完成。2024 年 1 月追著微信讀書改版修相容。2024 年 5 月最後一波功能收尾：優化書號取得、換圖示、修打包異常，5 月 14 日之後程式功能一行都沒再動過。2025 年 6 月 7 日唯一的後續提交是改 README；三週後 Chrome 商店版 1.1.0 更新，也就是目前的最新版。順帶一提，155 顆星對 928 位使用者，用的人不少，回來按星的很少，這是工具型擴充的常態，也代表它的生存高度依賴作者一個人的意願。

還有一個小地方從外部看不到答案：商店版 1.1.0 更新於 2025 年 6 月底，repo 裡附的安裝包卻停在 2024 年 5 月 14 日，中間這一年商店包多了什麼、改了什麼，只有作者自己知道。在意「我裝的程式碼就是我讀過的程式碼」的人，可以走手動安裝那條路：原始碼都在，讀完再裝，心裡踏實。

之後的故事搬到 issue 區。2025 年 8 月 14 日，有人開了一則回報，標題大意是功能好像不行了、評論載入不出來，時間點落在最後一次商店更新後六週。這則 issue 開到今天，作者沒有回應。同年 10 月 26 日另一位使用者問側欄怎麼關掉，作者倒是回了，大意是：還沒做關閉功能，建議先把擴充停用。

兩則擺在一起看很清楚：作者還活著、還會看 issue，只是不再寫碼。壞掉回報沒有修復、沒有解釋，也沒有人接手。依附型工具最怕的「上游改版、下游棄守」，在這裡同時發生了。

伺服器還在，壞的多半是接縫

它到底壞了沒？我直接請求擴充在用的那個評論端點：伺服器仍然有回應，匿名狀態下拿到的是空資料。這合理，因為評論本來就該跟著登入 cookie 走。這代表騰訊的評論服務沒有關，問題更可能出在頁面結構或參數又變了，也就是接縫又斷了一條，而這次沒有人去接。唯一的故障證據是 2025 年 8 月那則單一使用者回報，影響範圍多大、現在還犯不犯，從外部無法確認。壞掉的樣子倒是可以從程式碼推測：評論清單是空的時候，側欄只會顯示一行邀你點擊重新載入的提示，你點了，它再請求一次，還是空的。那則回報描述的「載入不出來」，跟這種安靜的空狀態正好吻合。

另一個容易踩的坑是功能預期。有中文介紹文把支援評論排序、支援點讚、發表評論寫成它的現有功能；翻開原始碼，排序、點讚、發表評論通通沒有實作，README 把這三項列在「功能規劃」區塊，從 2023 年一路列到停更。它實際會做的事只有：顯示該章評論、展開收合評論引用的原文、切換章節時自動重新載入（評論為空時可點提示手動重載）。評論的順序也不能調，端點回來什麼順序就顯示什麼順序。以為能互動、裝了發現只能看，是這個工具預期落差的高發區。

登入牆、簡中介面與寬螢幕門檻

裝之前，有幾個邊界要自己先秤一秤。

需要登入。實測同一個評論端點，匿名狀態只拿得到空資料，側欄要的是你登入中的連線；擴充不經手登入流程，只借用瀏覽器裡現成的 cookie。台灣讀者若本來就有微信帳號，這條不算負擔；沒有的人，為了一個側欄去辦微信帳號不划算。中國內容服務在台灣的使用邊界，我們在 紅果短劇 一文也踩過類似的牆。

介面與內容都是簡體中文，側欄從計數文案到評論內容都是簡體原文呈現。中國開發者的工具對繁體使用者不一定友善，Z2H 字帖產生器 是少數繁體直接能用的正面案例；這個擴充相反，你要自帶讀簡體的適應力。

螢幕要寬。側欄寬度的計算公式寫死在程式碼裡：視窗寬度減 1100 像素。1920 的螢幕側欄有 820 像素，很寬裕；1366 的筆電只剩 266 像素，評論被擠成細條；再窄下去，閱讀區和側欄就開始互相傷害。它預設你是用大螢幕讀書的人。

沒有關閉開關。側欄不做開關、不收進抽屜，不想看只有一個辦法：到擴充頁面整個停用。這點作者本人親口證實過。雙欄閱讀模式另有已知問題：2024 年 11 月有人回報雙欄排版下評論載入不出來，那則 issue 同樣開著沒修。習慣把書頁攤成兩欄的人，先有心理準備。

登入之後側欄此刻長什麼樣，我沒有辦法替你先驗證：2025 年 8 月那則回報之後沒有修復紀錄，也沒有人回報它又恢復了。把它當一場五分鐘的實驗最健康：裝、開一本書、看側欄有沒有內容。有就賺到，沒有就停用，一分鐘內回到原狀。

誰該現在裝，誰該再等

該裝的人：平常就用網頁版微信讀書、螢幕夠寬、想看同章讀者在想什麼，並且接受它隨時可能失效。你的成本是商店裡點一下安裝，最壞結果是停用，資料面乾淨到不用擔心。

不該指望它的人：想要穩定的常駐配備，或主要衝著排序、點讚、發表評論而來。那些功能停在規劃清單上，接縫也兩年多沒人維修。對這群人，回到官方手機 App、或讓網頁版維持原樣，都沒有損失。

微信生態周邊的開源工具，文顏 是另一個樣本：同樣把命運綁在微信的介面約定上，同樣吃上游改版的風險。這類工具的價值判斷，從來不在功能清單寫得多滿，而在上游一改版、誰來接手。微信讀書評論擴充這題的答案，目前是沒有人。喜歡它的構想就用行動投它一票，裝來試；需要它恆久運作，答案已經寫在 issue 區了。