如果您的機器人遇到速率限制錯誤，請別擔心——這是很常見的情況，只要採取正確的做法就能解決。 這篇文章將幫助您理解 Discord 的速率限制系統並提供實用的解決方案。
內容
了解 Discord 的速率限制類型
Discord 使用多種類型的速率限制來保護 API。 分辨出您遇到的是哪一種類型的速率限制，對於找到正確的解決方案是非常重要的：
全域速率限制
限制：大多數端點每秒最多 50 次請求
範圍：適用於整個應用程式
辨識方式：查看回應頭欄位中的 X-RateLimit-Scope: global
各路由的速率限制
限制：依端點而異
範圍：針對特定的 API 路由
辨識方式：查看 X-RateLimit-Scope: user
特定資源的速率限制
請注意：特定資源的速率限制可能是由多個來源（其他使用者、機器人、webhooks等）共同造成的，這不一定表示您的應用程式本身就是唯一的原因。
限制：針對特定公會、頻道或 Webhook 設有獨立限制
範圍：適用於特定資源的操作。
辨識方式：查看回應頭欄位中的 X-RateLimit-Scope: shared
無效請求限制
限制：每 10 分鐘最多 10,000 次無效請求
常見原因：未處理的錯誤（401、403 或 429）導致請求激增。 請注意，帶有 X-RateLimit-Scope: shared 的 429 錯誤不會被計入無效請求的限制中。
結果：暫時被 Cloudflare 封鎖
如何分辨您的速率限制問題
判斷您遇到的限制的最可靠的方法是檢查當您收到 429 狀態碼時的 HTTP 回應頭欄位。 檢查以下關鍵回應頭欄位：
X-RateLimit-Limit：該端點的速率限制上限
X-RateLimit-Remaining：當前窗口中剩餘的請求數
X-RateLimit-Reset：速率限制窗口重設的時間（Unix 時間）
X-RateLimit-Reset-After：距離限制重設還有幾秒
X-RateLimit-Scope: 表示速率限制的類型（全域、使用者或共享）
retry_after：在發送另一個請求之前要等待的毫秒數
處理速率限制的最佳做法
實施適當的退避策略
務必遵守速率限制回應中的 retry_after 值。 這告訴您在重試之前應該等多久。
請考慮盡可能使用互動式操作
應用程式指令 和 訊息元件是取代前綴指令的絕佳選擇，這可以減少過多的 API 請求以及頻道中的訊息數量。
額外小提示：將互動回應與後續訊息設為短暫顯示，因為這類訊息不會計入速率限制。
有效快取資料
透過快取常用資料來減少 API 呼叫次數，例如：
- 公會資訊
- 頻道詳情
- 使用者個人資料
- 身分組資料
使用請求節流
請求節流是一種主動防止觸發速率限制的方法，透過在達到限制前控制請求的速度。
例如，如果您的機器人需要向 200 位新成員發送歡迎訊息，與其一次性發送全部 200 則訊息，不如將它們加入佇列中，每 100 毫秒釋放 4 次請求。 這樣可以維持每秒 40 次請求的穩定速率，安全低於 50 次的限制，同時在大約 5 秒內完成所有訊息的傳送。
全域速率限制
如果您觸發了全域速率限制，代表您的程式可能存在需要修正的潛在問題。
以下是讓您的程式保持在速率限制內的優化建議：
- 實施適當的快取
- 移轉至互動式功能
如果這些做法仍無法解決全域速率限制的問題，我們建議您加入 Discord 開發者伺服器的 #api-help 頻道中尋求協助或聯繫開發者客服。
閘道注意事項與分片處理
對於透過 Discord 閘道（WebSocket 連接）處理即時事件的機器人來說，隨著規模成長，分片是不可或缺的。
什麼是分片？
分片是指將您的機器人拆分為多個執行實體，每個實體處理部分的公會。 這種方式能將負載分散到多個 WebSocket 連接上，有助於您保持在速率限制之內。
建議當您的機器人接近 2,000 個伺服器時就開始規劃分片的實作，當超過 2,500 個伺服器時，則必須啟用分片。 為了獲得最佳性能，請遵循每 1,000 個公會保持約 1 個分片的最佳做法。
請留意，速率限制的存在是為了確保所有 Discord 使用者都能擁有穩定的體驗。 遵循這些最佳做法，您可以建立一個有效運作同時不會違反限制的機器人，。