LIHKG 爬蟲冇官方文件：分台列表／關鍵字搜尋／單帖留言三種模式要分開刻，自己寫 vs 用現成 actor
一句話： LIHKG 冇官方 API 文件，自己刻 lihkg 爬蟲之前，要先搞清楚分台列表、關鍵字搜尋、單帖留言三種模式各自嘅輸入輸出同分頁機制完全唔一樣，唔係一套邏輯就打得三種端點——定係直接用已經處理好呢啲坑嘅現成 actor。
連登冇官方 API 文件，你面對嘅係乜
連登（LIHKG）作為香港最大嘅討論區之一，一直都冇發布過正式嘅開發者 API 文件。開發者社群要攞資料，靠嘅係逆向工程佢個未公開支援嘅 api_v2 JSON 端點——GitHub 上就有人專門紀錄點計算佢驗證要求嘅 x-li-digest signature，而且討論中途已經改過一次計算方式，即係話舊方法隨時可能失效，冇任何官方承諾會保持穩定。
目前公開讀取主題列表、搜尋同留言呢幾個端點唔需要帳號或驗證 header，但呢個狀態冇保證——連登隨時可能加上 X-LI-DEVICE 之類嘅驗證要求，或者乾脆擋資料中心出口 IP。想自己刻一套 lihkg 爬蟲嘅開發者，第一步要先搞清楚自己要攞嘅係哪一種資料形狀，因為三種模式嘅坑完全唔同，唔可以一套分頁邏輯打三種端點。
三種模式，資料形狀完全唔同
分台列表（thread-list） | 關鍵字搜尋（search） | 單帖留言（thread） | |
|---|---|---|---|
| 輸入 | catIds（分台ID，可填 all 展開全部 37 個可發文分台） | keywords（送去全站搜尋查詢） | threadIds / threadUrls |
| 輸出 | 主題列表，content 為 null，只有標題與元資料 | 搜尋結果，格式同列表一樣但不限分台 | 主文全文 + 全部留言（留言用 floor 樓層編號） |
| 排序/過濾 | 可用 keywords 做標題過濾（不擴大範圍） | order：最新回覆／最新發文／相關度三選一 | 可用 maxReplies 限制每串抓幾個樓層 |
| 計費 | search-listing，$0.002／篇 | search-listing，$0.002／篇 | 主文 product-detail $0.008／篇 ＋ 留言 review-item $0.003／則 |
| 用途 | 掃描指定分台有咩新主題 | 跨分台監控品牌／產品關鍵字 | 深挖單一熱門討論串嘅完整對話 |
最容易搞混嘅係 keywords 呢個欄位喺兩個模式入面行為完全唔同：search 模式送去連登全站搜尋，回傳嘅係搜尋結果；thread-list 模式嘅 keywords 只係喺已經攞到嗰個分台列表裡面做標題過濾，唔會幫你擴大到其他分台。自己刻嘅時候，呢兩個同名唔同義嘅參數好容易寫錯。
自己刻 vs 用現成 actor，差喺邊幾樣
想自己刻，以下幾樣係避唔開嘅工程問題：
分頁停止判斷——連登嘅列表同搜尋端點都要翻頁攞齊資料，但唔可以無限翻到底：翻到舊資料、重複資料就應該停，否則會空轉燒 request、甚至觸發限流。排程監控時仲要配合時間過濾（例如只要「呢個時間之後有新動靜」嘅主題），一過咗門檻就提早停止翻頁，唔使逐次由頭攞晒。
樓層編號唔連續——單帖留言模式攞返嘅留言用 floor（樓層）編號，但刪咗嘅留言唔會喺輸出入面出現，所以「攞頭 N 個樓層」唔等於「攞到 N 則留言」，實際筆數可能略少於 N。自己刻嘅時候如果假設樓層數等於回覆總數，計費同資料量都會估錯。
HTML 要自己清理——留言原始內容夾雜 <br>、<img>、<span> 之類嘅 HTML 標籤同埋 HTML 實體（&、<），要自己寫邏輯剝標籤、解碼實體先變成乾淨嘅純文字，唔係直接拎到就係可讀文字。
未來反爬風險冇得預先解決——連登目前對公開讀取端點冇要求驗證 header，但呢個狀態可以隨時改變；GitHub 上已經有人逆向工程過佢私有 API 用嘅 x-li-digest 簽名機制，可見連登本身有能力加驗證層。自己刻嘅爬蟲一旦遇到呢種升級，要重新逆向工程；靠現成 actor 嘅好處係有人持續盯緊呢個風險，壞咗會第一時間知道，唔用自己日日去查連登有冇改版。
決定點揀，睇呢三樣：
- 規模——一次性、單一分台、小量資料，自己寫幾個鐘通常搞得掂，冇必要為咗一次性需求去維護一套爬蟲。
- 頻率——要長期排程、監控多個分台或多個關鍵字，上面四個坑全部要自己處理一次，仲要長期維護。
- 反爬容忍度——如果連登升級驗證機制，自己刻嘅方案要自己重新逆向工程；用現成工具嘅話呢層風險由工具方持續監控。
實際要花多少
三種模式分項計費：
| 事件 | 單價 | 適用 |
|---|---|---|
search-listing（列表／搜尋每篇） | $0.002 | 分台列表、關鍵字搜尋 |
product-detail（單帖主文每篇） | $0.008 | 單帖留言模式嘅主文 |
review-item（留言每則） | $0.003 | 單帖留言模式嘅每則回覆 |
熱門長帖留言數可以過千，單帖留言模式嘅花費會跟住留言數上升——如果只想要一個大概印象、唔需要全部留言，先用分台列表或搜尋模式掃一輪，再揀真正值得深挖嘅主題跑單帖留言，比每個主題都全文全留言攞一次划算。
三條路，挑一條開始
從最省事到最自由
FAQ
LIHKG 有冇官方公開嘅 API？ 冇。連登官方從來沒有發布正式嘅開發者 API 文件，開發者社群長期要靠逆向工程佢個 api_v2 JSON 端點攞資料——GitHub 上甚至有人專門紀錄點計算佢驗證用嘅 x-li-digest signature，而嗰套計算方式討論中途已經改過一次，舊方法隨時可能失效。
分台列表、關鍵字搜尋、單帖留言三種模式，輸入輸出有咩唔同？ 分台列表（thread-list）填分台 ID（catIds），攞返主題列表，content 欄位係 null，淨係得標題同元資料；關鍵字搜尋（search）填 keywords，送去連登全站搜尋查詢，回傳格式同列表一樣但唔限分台；單帖留言（thread）填 threadIds 或 threadUrls，攞返主文全文加全部留言，留言用 floor 樓層編號，呢個同前兩種模式嘅資料形狀完全唔同。
search 模式嘅 keywords 同 thread-list 模式嘅 keywords 有咩分別？ search 模式嘅 keywords 係送去連登全站搜尋嘅查詢字，回傳嘅係搜尋結果，唔限分台；thread-list 模式嘅 keywords 只係喺已經攞到嗰個分台列表裡面做標題過濾，唔會擴大搜尋範圍，兩個名字一樣但行為完全唔同，自己刻嘅時候好容易混埋一齊。
自己刻 lihkg 爬蟲一定會踩到咩坑？ 幾個：幾時停止翻頁先唔會空轉燒 request；單帖留言嘅樓層編號因為刪帖會唔連續，唔可以假設樓層數等於回覆總數；留言 content 原始 HTML 要自己剝標籤同解碼實體先變純文字；仲有連登官方隨時可能加驗證 header 或者開始擋資料中心 IP 嘅風險，呢個冇得預先解決，只能靠持續監控同備援方案。
三種模式點計費？ 分台列表同關鍵字搜尋都係每篇 $0.002；單帖留言模式嘅主文每篇 $0.008，留言另外每則 $0.003，熱門長帖留言數可以過千，計費會跟住留言數上升；另外平台對每次 run 收一次性嘅啟動費 $0.005，呢個係 Apify 自動收嘅，唔係 actor 程式碼自己計。
咩時候應該自己刻，咩時候直接用現成 actor？ 一次性、單一分台、小量研究，自己刻幾個鐘通常做得到；但要排程長期監測多個分台或多個關鍵字，自己刻就要重新處理翻頁停止判斷、樓層去重、HTML 清理，仲要自己承擔未來連登加反爬驗證嘅升級風險；現成 actor 已經處理呢堆工程問題，而且每日有 canary 監控，壞咗會第一時間知道。
延伸閱讀
- GitHub 上免費 proxy list（像 proxifly）幾千星，真的能拿來跑爬蟲嗎？：決定自己刻之後，下一個要處理嘅就係 proxy——呢篇拆解免費清單同 Apify proxy 嘅差別。
- Apify 跟 ScraperAPI 都打不贏 Dcard 的 Cloudflare？：呢篇用連登爬蟲實際遇過嘅 429 限流案例，示範「換 proxy 就解」同「換 proxy 都冇用」點分界。
- 投訴帖喺財經台、上班台先得十幾個回覆，幾時先燒到時事台？：決定用現成 actor 之後，呢篇教你點用
search模式撒多關鍵字嘅早期預警網。
作者 Chad 實際經營 30 多隻上架 Apify actor（含本文用到嘅 LIHKG-scraper），文中關於連登 api_v2 冇官方文件同社群逆向工程嘅說法對照 GitHub 上公開嘅逆向工程紀錄，actor 嘅模式、欄位與計費數字對照 actor 自己嘅 input schema 與 store 頁，查不到來源嘅嘢呢篇唔會寫。