一場 429 假扮 404 的偵探記：限流的讀寫分道

症狀：在自己的網站上點了幾篇文章，突然看到「找不到這則筆記」。筆記明明在。重新整理，又好了。

追兇

第一層：錯誤頁誤導。頁面把所有 API 失敗都當成 404 呈現——真兇是 429（請求太多），被謊報成「不存在」。訪客會以為內容被刪了，這比錯誤本身更糟。教訓：錯誤分流要誠實，429/500 與 404 是完全不同的故事。

第二層：為什麼會 429？全站限流是每 IP 每分鐘 60 發，聽起來很寬。但算一下一次瀏覽的真實成本：內文 + 統計數字 + 圖譜資料 + 文章裡的每一張圖片——點開一篇筆記是五到十發的組合技。再加上開發環境裡瀏覽器與 SSR 伺服器共用同一個 IP，配額瞬間見底。

第三層（真正的病灶）：圖譜資料在每次換頁時整張重抓。三個元件共用同一份圖，卻各自 fetch、無跨頁快取——一次瀏覽平白多四發。修法是模組級快取 + single-flight + 五分鐘 TTL：知識圖只在發佈時變動，session 內看到五分鐘前的圖毫無問題。

重新設計：讀寫分道

修完 bug，把限流哲學整個翻新：

• 公開 GET 放寬但有界（每端點 600/min/IP）：人類與 SSR 永遠踩不到，但單 IP 的笨腳本狂打全表掃描端點仍會被攔——這是資料庫保護的最後一道，不是防 DDoS 的（多 IP 攻擊本來就是 CDN 邊緣層的工作）。
• 寫入 POST 個別收緊（30/10/5 per min）：寫入才是濫打面。

帶走的三課

一，限流預設值要用「一次真實瀏覽的請求數」去驗算，不是拍腦袋。二，SSR 是你的頭號 API 消費者，它以單一 IP 之姿代表所有訪客。三，出現奇怪的 429 時，先找「誰在重複抓不變的資料」——省下來的請求比放寬的配額更值錢。