Guard 的疊層順序：限流要站在認證前面

平台有兩個全域 guard：限流（throttler）與 JWT 認證。它們的註冊順序是一個安靜但重要的安全決策：限流在前。

順序反過來會怎樣？帶著偽造或過期 token 的請求先被認證擋下、根本走不到限流——攻擊者可以用無效 token 無限次敲你的認證邏輯（含一次 JWT 驗簽的 CPU），暴力嘗試零成本。限流站前面，失敗的認證嘗試也照樣吃 IP 配額。順帶一提，限流本身的策略是另一篇的故事。

預設安全，例外顯式

認證的慣例設計成預設全鎖：全域 guard 對每個端點要求有效 token，開放端點用 @Public() 顯式豁免。反過來（預設開放、逐個加鎖）的失敗模式是「忘了加鎖的新端點裸奔」——預設安全下，忘記的後果只是「該公開的端點多要了一次登入」，兩種遺忘的代價天差地遠。

角色檢查再疊一層：@Roles('admin') 讀的是全域 guard 已經填好的使用者資訊，所以它不需要再掛一次 JWT guard——重複掛會讓 passport 驗證跑兩次，白繳一次驗簽的錢。這種「誰依賴誰的產出」的關係，值得在慣例文件裡寫成白紙黑字，不然每個新 controller 都會出現防禦性的重複裝飾器。

Refresh token 是合法的第二 guard

唯一合法在 controller 上另掛認證 guard 的場景：refresh token 端點。它走的是另一條 passport 策略（驗的是 refresh token 而非 access token），不是重複而是不同的門。access token 十五分鐘短命、refresh token 七天且以雜湊落庫、換發時舊票立即撤銷——這組節奏是「被偷的 token 能作惡多久」與「使用者多久被登出一次」之間的平衡點。