Threads bot 兩個「沒報錯卻沒發」的靜默坑
我用 Claude Code 做了一個每天定時自動發 Threads 的小 bot（bot＝一段幫你自動做事的程式），穩定跑了半年。這半年撞過的坑裡，最難抓的不是那種會跳紅字報錯的，報錯的至少你知道哪裡壞了。最陰的是「**沒報錯，但也沒發**」的靜默坑：某天你滑到自己的 Threads，才發現它已經好幾天沒動靜，程式卻一句錯都沒噴。
這種靜默失敗特別花時間，因為你連從哪查起都不知道。這篇把我撞到的兩個靜默坑攤開：一個是登入用的 token（token＝一組讓程式代你發文的通行碼）會悄悄過期，一個是 Threads 的發文方式不是一步到位。兩個都有具體症狀、根因、修法。讀完你會知道怎麼讓「沒報錯卻沒發」變成抓得到的東西。5 分鐘讀完。
靜默坑一：token 60 天悄悄過期，bot 從此不發也不報錯
先講答案：Threads 的 long-lived token（長效通行碼）大約 60 天就會失效，而且失效那天不會跳任何錯——bot 照常跑、照常結束，就是沒真的發出去。這是我最久才抓到的一個坑，因為前 59 天它都好好的，你完全不會防。
token 你可以想成「代替你發文的臨時通行證」。Threads 給的這張證有效期約 60 天，到期後拿它去發文，對方只會安靜地不收，不會大聲說「你過期了」。於是 bot 每天照跑，你以為一切正常，其實已經連續好幾天貼了個寂寞。
修法兩步，照做就不會再被它靜默掉：
- Step 1 — 排一個「每週自動換新通行證」的小工作。token 在到期前是可以拿舊的去換一張新的，把這個「換新通行證」的動作（技術上叫 refresh token）設成每週自動跑，就永遠不會走到 60 天那條線。
- Step 2 — 記下你上次換 token 的日期，設一個快到期前提醒你的鬧鐘（例如抓第 50 天，離 60 天大限還有緩衝）。就算自動換證哪天壞了，你也會在爆掉前收到提醒，而不是等某天滑到自己帳號才發現。
靜默坑二：Threads 發文不是一步，container 沒等好就 publish 會失敗
先講答案：Threads 的 Graph API（Graph API＝Meta 給程式用的官方發文介面）發文是「兩段式」：先建一個裝內容的 container（容器），中間等它就緒，再 publish（正式送出）。很多人照最直覺的方式一步就 publish，結果 container 還沒 ready，發文就失敗。
拆白話講：第一步你把貼文內容交給 Threads，它先幫你放進一個暫存的容器，回你一個容器編號。這個容器不是瞬間就準備好的，需要一點點時間。第二步你才拿那個編號說「這個，發出去」。如果你第一步做完立刻做第二步、中間不等，容器還沒備好，Threads 就會拒絕。
修法：在建 container 和 publish 中間，加一個大約兩秒的等待。就這麼簡單，但沒人第一次會知道要等，文件常常只給你兩個步驟，不會提醒你中間要停一下。加了這個等待，發文成功率就穩了。
真正的功課：怎麼讓「沒報錯卻沒發」變得抓得到？
先講答案：靜默失敗之所以難，是因為它不留痕跡，所以解法就是逼它留痕跡。在流程的每一步都加一行 log（log＝程式的執行紀錄，把「我做到哪、結果是什麼」寫下來），事後一對照就知道斷在哪。
我這兩個坑會卡那麼久，共同原因就是「中間沒紀錄」。token 過期那次，我只在最後看有沒有發出去，沒發就一頭霧水；後來我在「拿到 token」「建 container」「publish 回應」每一步都印一行紀錄，下一次一出事，我一眼就看到是 token 那步回了空的，馬上定位，不用再從頭猜。
這也是我做自動化這半年最大的體會：會噴錯的坑其實好命，因為它逼你當下處理。真正會拖垮你的是「安靜地壞掉」——所以任何無人看管、自己在背景跑的東西，都要先想好「它哪天默默死了，我怎麼會知道？」。
一句話總結，跟這篇在連載裡的位置
Threads bot 兩個靜默坑：token 約 60 天悄悄過期（排每週 refresh + 50 天提醒），發文要先建 container 等約兩秒再 publish（中間別急）。而抓靜默失敗的通用解法只有一個——每步加 log，逼它留下痕跡。
這篇是我把「我做的東西回頭反咬我」這條線再補一塊：#15 講 AI 幫我寫的內容在唬爛、#25 講帶流量的頁在拖累主題，這篇講我自己的 bot 在背景安靜地不發文。共同點都是「表面看起來沒事」最危險。下一站我會把這半年做過的幾個自動化 bot 的坑整理成一份總集。
我做的 Threads 自動發文 bot 穩定跑半年，最難抓的是「沒報錯卻沒發」的靜默坑。坑一：long-lived token 約 60 天靜默失效，bot 照跑但沒真發，修法是排每週自動 refresh + 記錄換 token 日期、設個快到期提醒（例如第 50 天）。坑二：Threads Graph API 發文是兩段式，要先建 container 再 publish，中間沒等約兩秒、container 沒 ready 就會失敗。抓靜默失敗的通用解法：每一步加 log 逼它留痕跡，出事一眼定位。核心體會：會噴錯的坑好命，安靜壞掉的最致命——任何背景自動跑的東西都要先想好「它默默死了我怎麼會知道」。5 分鐘讀完。
如果內容對你有用就太好了
隨喜斗內
相關文章
▸ 常見問題
Threads bot 沒報錯卻不發文，是怎麼回事？
最常見是 long-lived token（長效通行碼）到期了。Threads 的 token 約 60 天失效，而且失效不會跳錯，bot 照常跑完、就是沒真的發出去。修法：排一個每週自動 refresh token 的小工作（到期前拿舊的換新的），再記下換 token 日期、設個快到期提醒（例如第 50 天）當保險。並在每步加 log，才抓得到是哪一步靜默斷掉。
Threads Graph API 發文一直失敗怎麼辦？
Threads 發文是「兩段式」，不是一步：先建一個裝內容的 container（容器），等它就緒，再 publish（送出）。如果建完 container 立刻 publish、中間不等，容器還沒 ready 就會失敗。修法：在建 container 和 publish 中間加約兩秒的等待。這步文件常常沒提醒，所以第一次做幾乎都會踩。
為什麼「沒報錯」的失敗比會報錯的更難處理？
因為它不留痕跡。會噴錯的至少告訴你哪裡壞、逼你當下處理；靜默失敗是 bot 照跑照結束，你根本不知道出事，可能好幾天後才偶然發現。解法是逼它留痕跡：在流程每一步加一行 log（執行紀錄），事後一對照就知道斷在哪一步，不用從頭猜。
這些坑只有 Threads 會遇到嗎？
不只。任何「無人看管、在背景自動跑」的東西都有靜默失敗的風險，像 IG 自動發文、排程爬蟲、定時通知都一樣。通行碼會過期、外部接口會有你沒預期的步驟、免費服務會默默改規則。做任何背景自動化前，先問自己一句：「它哪天默默死了，我怎麼會知道？」把這個答案（通常就是 log + 提醒）先做進去。
看完這篇之前先確認:
- 自己做了 Threads / IG 自動發文 bot，某天發現它沒報錯卻也沒發的人
- 在接 Threads Graph API、發文一直失敗查不出原因的人
- 想學「怎麼讓沒報錯的靜默失敗變得抓得到」的人
- 還沒做過任何自動發文、只想看概念的人（先做一個再回來看這篇）
- 用現成排程工具（不碰 API）發文的人
- 要企業級發文佇列 / 監控系統的人（這是個人 bot 版）
- 以為 bot 沒報錯就是正常，結果它 60 天後靜默不發，你完全不知道
- Threads 發文照文件一步 publish，其實要先建 container、等它 ready 再發
- 只在最後看有沒有成功，中間沒 log，靜默失敗根本無從查起