PTT 爬蟲沒有官方 API：看板列表與單篇貼文兩種模式，自己刻會踩到哪些坑
一句話： PTT 爬蟲沒有官方 API 可以打，只有看板列表跟單篇貼文兩種模式——自己刻之前要先搞懂 over18 cookie 關卡、增量抓取的停止判斷，還是直接用已經處理好這些坑的現成 actor。
PTT 沒有官方 API，你面對的是什麼
PTT（批踢踢實業坊）本質上是一套 Telnet BBS 系統，核心程式 pttbbs 的原始碼公開在 GitHub：文字模式（Telnet）主程式放在 mbbsd 目錄，另外還有像 boardd（給網頁版用的看板文章服務）這類背景服務，把 BBS 內容橋接到 ptt.cc 網頁版。換句話說，官方從來沒有發布過一份文件化的網頁資料 API——想抓資料的開發者，要嘛自己解析網頁 HTML，要嘛逆向它的 BBS 協定。
這也是為什麼 GitHub 上長期有人維護自己的 PTT 函式庫：PyPtt 是一套用 Pure Python 實作、提供完整 PTT 功能的 SDK，目前有 734 顆星；jwlin/ptt-web-crawler 則是針對網頁版的爬蟲工具，有 451 顆星。這些專案存在本身就說明了一件事：沒有官方 API，社群就要自己造輪子。
想自己刻一套 PTT 爬蟲的開發者，第一步要先搞清楚自己要抓的資料形狀，因為看板列表跟單篇貼文兩種模式的坑完全不同。
兩種模式，資料形狀完全不同
看板列表（board） | 單篇貼文（post） | |
|---|---|---|
| 輸入 | boards（看板名稱陣列，例如 Gossiping、Stock、Tech_Job，PTT 區分大小寫） | postUrls（完整貼文網址陣列） |
| 輸出 | 貼文標題列表（標題、作者、推噓淨值、發文時間） | 主文全文 + 全部推噓文（推噓文用 floor 樓層編號） |
| 過濾 | 選填 keywords：只保留標題包含關鍵字的貼文 | 無獨立過濾，抓單篇就是全文 |
| 計費 | search-listing，每篇 $0.002 | 主文 product-detail $0.008／篇 ＋ 推噓文 review-item $0.003／則 |
| 用途 | 掃描指定看板有什麼新文章 | 深挖單一熱門討論串的完整對話 |
最容易搞錯的地方是看板模式的 keywords：它不是全站搜尋，純粹是抓完看板列表頁之後，在本地端用字串比對做標題過濾，不會呼叫任何搜尋端點。PTT 網頁版本身沒有提供官方的全站搜尋功能，這也是為什麼這裡只有兩種模式——不是偷工減料，而是 PTT 真的就沒有第三種端點可以打。這跟連登（LIHKG）有真正的全站搜尋端點不一樣：LIHKG 的 search 模式會送去它的全站搜尋查詢，PTT 沒有對應的東西。
自己刻 vs 用現成 actor，差在哪幾樣
想自己刻，以下幾樣是避不開的工程問題：
over18 cookie 關卡——18 禁看板（Gossiping 等）第一次連線會被導去年齡同意頁，要設好 over18=1 的 cookie 再重打請求才能看到內容，不能直接硬打原本的網址。這份公開的範例腳本示範了核心邏輯：偵測到導向 /ask/over18 頁面時，設定 over18 cookie（過期日期設到 2038 年避開 Y2038 問題），再導回原始文章網址。自己刻的時候，這個判斷跟重打的流程要自己處理一次。
增量抓取的停止判斷——要排程監控只抓新文章，得依文章 ID 的時間戳判斷，精確到秒；翻頁翻到整頁貼文都早於設定的時間才能停止翻頁，否則會空轉燒 request。這個邏輯寫錯，輕則重複抓資料、重則漏抓新文章。
HTML 要自己清理——單篇貼文的全文跟推噓文都是純 HTML 解析，簽名檔、發信站資訊（※ 發信站:那一行）要自己切掉才會變成乾淨的純文字，不是抓到就直接可讀。
未來改版風險冇得預先解決——PTT 公開讀取端點目前對直連友善，通常不需要 proxy，但這個狀態隨時可能改變。自己刻的爬蟲一旦遇到版面或驗證機制改版，要自己重新解析；用現成 actor 的好處是有人持續盯著這個風險，壞了會第一時間知道。
決定怎麼選，看這三樣：
- 規模——一次性、單一看板、小量資料，自己寫幾個鐘頭通常搞得定。
- 頻率——要長期排程監控多個看板或關鍵字，上面三個坑全部要自己處理一次，還要長期維護。
- 風險容忍度——PTT 一旦改版，自己刻的方案要自己重新處理；現成工具這層風險由工具方持續監控。
實際要花多少
用 ptt-scraper 的公開計費頁換算，兩種模式分項計費：
| 事件 | 單價 | 適用 |
|---|---|---|
search-listing（看板列表每篇） | $0.002 | 看板模式 |
product-detail（單篇主文每篇） | $0.008 | 單篇貼文模式的主文 |
review-item（推噓文每則） | $0.003 | 單篇貼文模式的每則推噓文 |
熱門長文推噓文數可以上百則，單篇貼文模式的花費會跟著推噓文數上升——如果只想要一個大概印象、不需要全部推噓文，先用看板列表模式掃一輪，再挑真正值得深挖的文章跑單篇貼文，比每篇都抓全文全推噓文划算。另外平台對每次 run 收一次性的啟動費 $0.005，這是 Apify 自動收的，不是 actor 程式碼自己計費。
三條路，挑一條開始
從最省事到最自由
FAQ
PTT 有官方公開的 API 嗎？ 沒有。PTT 本質上是一套 Telnet BBS 系統，核心程式 pttbbs 的原始碼公開在 GitHub（文字模式主程式與多個背景服務），ptt.cc 網頁版只是架在這套 BBS 系統上面的瀏覽介面，官方從來沒有發布過文件化的網頁資料 API。開發者社群長期要自己解析網頁 HTML 或逆向 BBS 協定，GitHub 上的 PyPtt（734 顆星）、jwlin/ptt-web-crawler（451 顆星）等第三方函式庫就是證明。
看板模式的關鍵字過濾，跟全站搜尋一樣嗎？ 不一樣，而且這是自己刻最容易搞錯的地方。看板模式的 keywords 只是在已經抓到的看板列表頁裡面做標題文字比對，純粹是抓完資料之後在本地端用字串比對做的過濾，不會呼叫任何搜尋端點、也不會擴大到其他看板。PTT 網頁版本身沒有提供官方的全站搜尋端點，這也是為什麼 ptt-scraper 只有看板列表跟單篇貼文兩種模式，沒有獨立的「搜尋」模式。
自己刻 PTT 爬蟲一定會踩到什麼坑？ 幾個：18 禁看板（例如 Gossiping）第一次連線會被導去同意頁，要設好 over18 cookie 再重打請求才能看到內容；想要排程監控、只抓新文章的話，dateFrom 要依文章 ID 的時間戳判斷、精確到秒，翻頁翻到整頁都早於這個時間才能停，邏輯寫錯就會整頁重複抓或漏抓；貼文全文跟推噓文都是純 HTML 解析，簽名檔跟發信站資訊要自己切掉才會乾淨。
看板列表跟單篇貼文兩種模式怎麼計費？ 看板模式（抓看板列表）每篇 0.002 美元；單篇模式的主文每篇 0.008 美元，推噓文另外每則 0.003 美元，熱門長文推噓文數可以上百則，計費會跟著推噓文數上升。另外平台對每次 run 收一次性的啟動費 0.005 美元，這是 Apify 自動收的，不是 actor 程式碼自己計費。
什麼時候該自己刻，什麼時候該直接用現成 actor？ 一次性、單一看板、小量研究，自己刻幾個鐘頭通常做得到；但要長期排程監控多個看板或關鍵字，over18 cookie 流程、dateFrom 增量停止判斷、HTML 清理這幾個坑都要自己處理一次並長期維護，還要自己承擔 PTT 未來改版的風險。現成 actor 已經處理完這些工程問題，而且每天有 canary 監控，壞了會第一時間知道。
延伸閱讀
- LIHKG 爬蟲冇官方文件：分台列表／關鍵字搜尋／單帖留言三種模式要分開刻，自己寫 vs 用現成 actor：同一套「自己刻 vs 用現成 actor」的判斷方式，套到連登身上——連登有真正的全站搜尋端點，跟 PTT 沒有這一塊剛好是個對照。
- PTT 輿情監測要請人嗎？老闆花 3–4 萬月薪找人巡版，這份工作能自動化到什麼程度：同樣用 ptt-scraper，但比的是「雇人巡版」跟「排程爬蟲」的人力成本，跟本篇「自己刻」跟「用現成 actor」的技術決策是不同的比較軸線。
作者 Chad 實際經營 30 多隻上架 Apify actor（含本文用到的 ptt-scraper），文中關於 PTT 沒有官方 API、pttbbs 原始碼與社群函式庫星數的說法對照 GitHub 公開頁面，actor 的模式、欄位與計費數字對照 actor 自己的 input schema 與原始碼，查不到來源的東西這篇不會寫。