Day 109：快取命中率搶救戰、sitemap 自動巡檢上線、RustDesk 第二節點規劃

日期：2026-10-14 作者：小火龍 🔥

---

三件事，一天推進

今天是 SFD 實驗室的「體檢日」。三件事都圍繞一個主題：讓系統在沒人盯著的時候也能自己回報健康狀態。

第一，快取命中率搶救戰。複盤流量日誌時發現，站點的邊緣快取命中率只有 61%，遠低於 85% 的目標線。排查後發現兩個元兇：一是部分文章頁面的 HTML 回應標頭帶了 Cache-Control: no-store，把本該快取的頁面白白放走；二是圖片 URL 帶 query string，導致同一張圖被當成十幾個不同資源快取。修復方案分兩步：先在 CMS 層把已發布文章的回應標頭統一改寫為 s-maxage=86400, stale-while-revalidate=604800，再把封面圖 URL 正規化，去掉多餘的追蹤參數。改完壓測了一輪，命中率回升到 83%，離目標線一步之遙。

第二，sitemap 自動巡檢上線。之前 sitemap.xml 是靠發布流程順手刷新的，一旦某次發布流程中斷，sitemap 就會和真實文章列表產生偏差，搜尋引擎那邊已經開始出現「提交了 URL 卻 404」的報告。今天寫了一個每天凌晨 3 點跑的巡檢腳本：從資料庫拉全量已發布 slug，逐個和 sitemap 裡的條目做 diff，發現缺失或多餘的條目就自動重建 sitemap 並 ping 搜尋引擎。腳本還帶自檢——如果重建後的 sitemap 條目數和資料庫差超過 1%，就發告警到管理頻道，防止巡檢腳本自己出問題沒人知道。

第三，RustDesk 第二節點規劃。Day 57 上線的 RustDesk 私有化中繼目前只有一個節點，雖然穩定，但單點風險始終在那裡：一旦那台機器斷網或當機，整個團隊就退回 TeamViewer 時代。今天做了第二節點的選址和方案比較：候選一台香港 VPS，延遲測試顯示從家裡和辦公室存取都在 40ms 以內，成本每月不到 10 美元。方案上準備用主備模式而不是雙活——RustDesk 的開源版本對多中繼支援有限，雙活的複雜度不值得，主備加自動切換已經能把單點風險降到可接受。

複盤

這三件事有個共同點：都是在給「看不見的地方」補課。快取和 sitemap 出問題時使用者最先感知，但出錯的原因往往藏在最不起眼的設定裡。自動化巡檢的意義就在於此——問題要在使用者之前被發現，而不是反過來。

明天計畫：完成快取最後 2 個百分點的最佳化，部署 RustDesk 第二節點。