Rate limit contract 是限流機制對外承諾的語意邊界，回答消費者被擋下之後能依賴什麼。Rate Limit 卡描述限流保護誰、限制什麼資源；rate limit contract 卡描述限流被觸發之後，消費者拿到的訊息是不是可以直接寫進重試邏輯的承諾，還是只是參考用的提示。

概念位置

限流的執行機制在 gateway 層，對外語意在契約層——執行機制常見用 Token Bucket 之類的演算法計算剩餘配額，但這個數字對外暴露時是不是一份承諾，是契約層要單獨定義的事。配額資訊的第一條原則是劃出承諾邊界——動態剩餘量 header 是預警而非保證，服務端保留在異常流量下提前收緊的權利，消費者的正確姿勢是把拒絕狀態處理寫對，而不是精算剩餘配額。被拒絕之後的最小可承諾集合是：狀態碼用 429（跟終態的 4xx 區分，讓消費者知道可以重試但要等）、Retry-After 給出等待時間、且服務端要說到做到——等滿再來就該被服務，否則這個 header 淪為裝飾，消費者會退回盲目重試。

可觀察訊號與例子

GitHub 的限流文件在拒絕狀態碼上有明確的語意瑕疵：超限可能回 403 也可能回 429，文件沒有清楚劃分兩者的使用時機，消費者因此要同時處理兩種狀態碼，分支邏輯多一倍。同一份紀錄也顯示單一維度的請求計數擋不住真實濫用——GitHub 除了每小時的 primary limit，還設了並發上限、單端點吞吐、CPU 時間等 secondary limits，因為額度內的高並發、額度內的單端點轟炸都是額度數字量不到的濫用模式。

判讀方式

判斷一個限流實作的契約是否可信，檢查拒絕狀態碼是否只用一種、Retry-After 是不是等滿就真的放行。限流回 500 是常見設計錯誤——消費者會把它當成服務故障告警，但成因是自身超額，這個語意錯位會讓消費者做出錯誤的降級判斷。被擋下之後的重送安全跟冪等語意在消費端匯合：429 之後的重送，要嘛操作本身冪等，要嘛帶 Idempotency Key。