效能與規模 是做什麼的？
概述
效能是一項有預算的功能。測量它、限制它，並記住今天的行為會成為明天的合約。系統很少因為你設計的吞吐量而崩潰——它們崩潰在你沒有建立索引的查詢，以及你沒有分頁的列表上。
原則
- 設定預算並據此測量。 延遲目標（與
observability-and-slos的 SLO 相關）和客戶端預算（例如打包大小）。超出預算的回歸即為錯誤。 - 先測量再最佳化。 在修改程式碼之前，先用資料找出真正的瓶頸——分析報告、查詢計畫、追蹤。沒有投機式最佳化。
- 預設分頁。 任何可能增長的列表都應以設有上限的頁面大小進行分頁。無限制的結果集會造成延遲與拒絕服務的風險。
- 留意 N+1 存取模式。 在迴圈中擷取資料是最常見的規模化失敗原因；應改用批次或聯結。（在此技術棧上：使用 GraphQL 層的 look-ahead/DataLoader，而非逐行解析。）
- Hyrum 定律是真實存在的：介面的每個可觀察行為，一旦有足夠多的消費者，就會變成某人依賴的合約——包括你從未意圖的行為（排序、可空性、錯誤形狀、時序）。將公共介面（特別是 API/架構）視為合約：新增與棄用，不要默默修改。
graphql-contract-testing的合約測試固定了你選擇的行為；紀律則保護那些你未選擇的行為。
快速參考
| 氣味 | 修正方式 |
|---|---|
| 迴圈內有查詢 | 批次或聯結；使用 look-ahead |
| 無限制的列表端點 | 加入有上限的分頁 |
| 「讓我最佳化這個」但未經測量 | 先分析；找出真正的瓶頸 |
| 修改欄位的型別/可空性/順序 | 這是合約變更——新增新的，棄用舊的 |
| 沒有延遲或打包目標 | 設定預算；將回歸視為錯誤 |
強制執行： 可在 CI 中機械化檢查的預算（打包大小限制、查詢成本限制）；分頁與 N+1 的避免則仰賴審查者的判斷，並輔以負載測試與查詢計畫審查。
完整理由：憲法第十一條，收錄於 engineering-constitution/references/engineering-constitution.md。