用關鍵字抓 Threads 貼文的 3 種方法：官方 API 的真實門檻、自寫爬蟲、還是用 Apify 現成 actor

一句話： Threads 其實有官方關鍵字搜尋 API，但它有三個真實門檻——要通過 Meta App Review、滾動 24 小時限 2,200 次查詢、回傳欄位不含任何互動數據；自己寫爬蟲最自由但維護最重；用現成的 Apify actor 免登入免 token、$0.005／筆、讚數轉發數齊全。三條路的門檻和取捨，這篇攤開講。

「Threads 沒有搜尋 API」——這說法過時了，但門檻是真的

Threads 的月活躍用戶在 2025 年 8 月突破 4 億（Meta 官方公告、TechCrunch 報導）。量體到這個程度，做品牌監測、追 KOL、寫競品報告的人都會問同一個問題：我要怎麼用「關鍵字」把 Threads 貼文撈下來？

網路上很多文章還在說「Threads 沒有開放搜尋 API，只能爬蟲」。這說法過時了：官方 Threads API 有一個 keyword_search 端點，可以用關鍵字搜公開貼文。但它有幾個文件上白紙黑字的限制——要通過 App Review 才搜得到公開貼文、每個 user token 滾動 24 小時限 2,200 次查詢、而且回傳欄位裡沒有讚數、轉發數、瀏覽數。

所以「官方 API 能不能用」，完全取決於你拿資料要幹嘛。實務上你有三條路，先看總表。

先看總表

下面把每條路的細節拆開。

方法一：官方 Threads API 的 keyword_search

官方路線的流程（文件在此）：

1. 在 Meta for Developers 建一個 app，接上 Threads API。
2. 取得 threads_basic 和 threads_keyword_search 兩個權限。注意：threads_keyword_search 要通過 App Review 才能搜「公開貼文」；沒過審之前，這個端點只會回你自己帳號的貼文。
3. 拿到 user access token 之後，打這個端點：

curl -s -X GET \
  -F "q=台積電" \
  -F "search_type=RECENT" \
  -F "fields=id,text,media_type,permalink,timestamp,username" \
  -F "access_token=<THREADS_ACCESS_TOKEN>" \
"https://graph.threads.net/v1.0/keyword_search"

文件明列的限制：

• 滾動 24 小時內每個 user 最多 2,200 次查詢。同一個關鍵字重複查也算次數；查無結果的查詢不計。
• 單次查詢預設回 25 筆、最多 100 筆；search_type 可選 TOP（預設，熱門）或 RECENT（最新）；since／until 可篩日期（Unix timestamp）。
• 文件範例列的回傳欄位如 id、text、media_type、permalink、timestamp、username、has_replies、is_quote_post、is_reply 等（完整欄位見 Media 物件文件）——但整份 Media 物件裡都不含讚數、轉發數、瀏覽數這類互動指標；那些只在 Insights API，而且僅限你自己的貼文。

最後這點是關鍵：如果你要做的是輿情排序（哪篇聲量最大）、KOL 成效（哪篇爆了）、競品內容分析（什麼形式互動最好），拿不到互動數據的搜尋結果，基本上做不了這些事。官方 API 適合的是「我只要知道有誰在講什麼」的告警型用途，而且你的團隊本來就熟 Meta 的開發者申請流程。

方法二：自己寫爬蟲

最自由的一條路，也是隱形成本最高的一條。以我自己維護 Threads 爬蟲的實際經驗，你會遇到的是：

• Threads 網頁版是 client-side render——貼文內容不在初始 HTML 裡,要嘛逆向它的內部資料端點,要嘛跑真瀏覽器去等頁面渲染。
• 內部端點沒有文件、改版不會通知你。今天能跑的程式碼,下次 Threads 前端改版就可能整批失效,而你只會在資料斷掉時才發現。
• 反爬與頻率限制自己扛——proxy、退避重試、封鎖偵測,都是你的維運範圍。

寫一次當學習專案完全可以。但如果這條管線要每天穩定餵資料給你的報表或客戶，真正的成本不是第一版程式,而是之後每一次改版的跟進維護。這筆帳建議誠實算進去（我們在DIY 輿情成本那篇把「自己接」的帳算得更細）。

方法三：用 Apify 現成 actor，五分鐘跑起來

第三條路是用別人維護好的爬蟲。以我自己上架的 threads-feed-scraper 為例（上架至今 114 位用戶、4.89★，數字見 store 頁），它的「搜尋模式」就是為這個場景做的：不用登入、不用 API token、不用過 App Review，在 Apify Console 填這段輸入就能跑：

{
  "mode": "search",
  "keywords": ["台積電", "護國神山"],
  "searchSort": "recent",
  "dateFrom": "7 days",
  "maxPosts": 100
}

幾個實戰要點（欄位定義以 actor 的 input schema 為準）：

• keywords 是陣列，一次最多 100 個關鍵字；每個關鍵字最多抓 500 篇（maxPosts，預設 50）。
• 一個概念一個關鍵字。Threads 搜尋會把整串當一個詞匹配，複合詞像「冥想正念」會回 0 筆——拆成「冥想」和「正念」分開放。
• searchSort 選 top（熱門）或 recent（最新）；做每日監測用 recent 配 dateFrom: "7 days" 這種相對日期最順手。
• 輸出欄位含 likeCount、replyCount、repostCount、shareCount、viewCount、quoteCount 和 ISO 8601 時間戳——官方 API 拿不到的互動數據，這裡是完整的，可以直接做聲量排序和情緒分析。

費用是每筆結果 $0.005、按實際抓到的筆數計（store 頁定價）：抓 50 篇是 $0.25，抓滿 500 篇是 $2.50。抓下來之後要接分析或自動化，可以走 n8n（我們有一篇手把手教學）。

挑一條開始

從最省事到最自由

我幫你跑 代管，每天送到你的表 你什麼都不用做。每月 US$299 起。 直接在這用 跑免費工具 即時、免設定、就在本站。 跑我的 actor 用你自己的 Apify 帳號 同一份資料，你自己跑、按筆計費。 自己動手建 免費註冊 Apify 開免費帳號，自己把管線建起來。

本文含 Apify 推薦連結（不影響你的費用）。文中的成本與比較都據實列出，包含 Apify 不划算的情況。

FAQ

Threads 到底有沒有官方搜尋 API？ 有。keyword_search 端點可以用關鍵字搜公開貼文，但要通過 App Review 取得 threads_keyword_search 權限（沒過審只能搜到自己的貼文）、滾動 24 小時限 2,200 次查詢，且回傳欄位不含讚數、轉發數等互動數據。

官方 API 的 2,200 次限制夠用嗎？ 看用途。單純告警（每小時查幾個關鍵字）綽綽有餘；但單次查詢最多回 100 筆、又拿不到互動數據，要做聲量排序或歷史回補就不合適。

為什麼我搜複合關鍵字會回 0 筆？ Threads 搜尋把整串文字當一個詞匹配。「冥想正念」這種複合詞常常搜不到東西，拆成兩個獨立關鍵字分別查就正常了。actor 端這是實測結論（見它的 input schema 說明）；官方 keyword_search 沒有文件化關鍵字的匹配方式，推測行為相同（同一搜尋後端），但未經官方證實。

用 actor 抓的資料有讚數和瀏覽數嗎？ 有。輸出含 likeCount、replyCount、repostCount、shareCount、viewCount、quoteCount，這是它跟官方 keyword_search 最大的差異。

用 actor 需要 Threads 帳號或 token 嗎？ 不用。它抓的是公開頁面內容，不需要登入、不需要 Meta 開發者帳號、不需要 access token。

這樣抓合法嗎？ 我們只抓公開內容、不碰需要登入的資料，也不儲存超出公開頁面呈現的個資。使用任何方法前，建議自行確認你所在地區的法規與平台條款對你的用途的適用性。

作者 Chad 實際經營 40+ 隻上架 Apify actor，本文用到的 threads-feed-scraper 是其中之一（上架至今 114 位用戶、4.89★，數字見 store 頁）；官方 API 的每一個限制數字都附了 Meta 官方文件連結，查不到來源的東西這篇一律不寫。