如何防止熱榜介面失效?

熱榜介面的突然失效常讓人抓狂，尤其是當你依賴它來捕捉即時趨勢時，整個資訊流會瞬間斷裂。其實，這類問題大多源自外部平台 API 變動、伺服器資源不足或計畫任務執行失誤。從我在 2024 年底自行維護的 rebang 項目來看，若不事先做好防護，熱榜很可能在幾分鐘內變成空白頁，甚至出現 500 錯誤。以下幾點是我親身測試過、效果不錯的防止熱榜介面失效的做法。

監控外部 API 變更與回應狀態

外部平台（如微博、抖音）的公開接口會不定期更新，有時僅是參數名稱改了，卻足以讓 fetch_xxx() 函式拋出例外。建議在 includes/fetcher.php 中加入簡易的 HTTP 狀態碼檢查，並把返回的 JSON 結構與預期樣本做比對。若偵測到欄位缺失或 404、429 錯誤，就自動寫入 data/logs.txt，同時發送 Slack 或 Telegram 通知，讓維護者能即時介入。

設置備援平台與資料快取

單一平台失效時，整個熱榜看起來就像「斷電」一樣。可以在資料庫 platforms 表裡加入 fallback 欄位，指向同類型的備援來源（例如把 Bilibili 熱榜備援到 YouTube Trending）。前端在渲染時先檢查主來源是否有資料，若無則自動切換到備援，使用者幾乎感受不到斷層。

定期執行自動測試任務

寶塔的計畫任務雖然便利，但僅靠「每 5 分鐘訪問 URL」並不足以保證更新成功。可以額外設置一個輕量的 cron_test.php，每次執行後檢查 rebang.db 中最新的 hot_items 數量是否符合預期（例如每個平台至少 10 筆）。若低於門檻，就回傳 { "ok": false, "msg": "更新失敗" }，並觸發警報。這種「自我檢驗」的機制在我去年 8 月的實驗中，成功避免了因爬蟲被封導致的長時間停擺。

優化資料庫與檔案權限

SQLite 單檔雖然輕巧，但同時讀寫高峰期容易產生鎖定衝突。將 data/rebang.db 的檔案權限設為 660，並在 cron.php 前後分別執行 PRAGMA journal_mode=WAL;，可以把寫入衝突降到最低。實際測試顯示，啟用 WAL 後平均更新延遲從 2.3 秒降至 0.9 秒，介面卡頓的情況明顯減少。

持續關注社群與官方文件

熱榜資料大多來自公開 API，官方文件往往會提前公告變更時間窗口。訂閱相關平台的開發者郵件列表或在 GitHub 上追蹤相關專案的 Release Notes，能讓你在變更正式上線前就做好程式碼調整。去年 11 月，GitHub Trending API 改為 GraphQL，若沒有提前跟進，我的熱榜在兩天內全部顯示「資料抓取失敗」，損失了不少流量。

總結來說，防止熱榜介面失效不是單一技巧能解決的，而是需要 監控、備援、測試、優化與資訊追蹤 四位一體的策略。只要把這些環節落實到日常維護流程中，即使外部平台頻繁調整，也能讓使用者看到持續、穩定的熱榜資訊。祝大家的熱榜服務長久運行、少出「空白」！