這幾乎是每個大廠都會上演的羅生門。

有一次大促銷活動前夕，App 端突然瘋狂閃退。一查 Log，發現原本回傳商品價格的欄位 price，從字串 "100.50" 變成了數字 100.5。App 端解析失敗，直接拋出 Null Pointer Exception 暴斃。

把寫 API 的後端抓來問，他竟然說：「我覺得數字本來就該用 Int 或 Float 啊，之前那個學長寫字串太蠢了，我順手 refactor 了一下。」

這時候最精采的來了。這位後端發現自己惹禍，馬上跑去 Jira 上面偷偷補了一個 Ticket，然後在 Slack 上裝死說：「我有開卡啊，是前端自己沒看信通知、沒處理好 Exception。」這就是標準的辦公室政治：出了事，先想辦法把鍋甩給那個防禦力最弱的人。

面對這種喜歡「順手改規格」的天才，你不能用嘴巴跟他吵，你必須用「契約測試（Contract Testing）」跟「追溯機制」來釘死他。

消費者驅動契約測試（Pact Testing）
不要依賴人與人之間的口頭溝通。在 CI 階段導入 Pact 這類的 Contract Testing 工具。前端把預期收到的 JSON 格式寫成一份 Contract 丟在 Repo 裡，後端的 CI 每次 Build 之前，都必須跑過這份 Contract。
只要後端敢偷改欄位名稱或是變更型別，CI 會直接賞他一個大紅燈，連 Merge 的按鈕都按不下去。

Swagger/OpenAPI 鎖死與變更稽核
API 文件不是寫給人看的，是寫給機器驗證的。我們直接設定 API Gateway 層級的 Schema Validation。如果你回傳的 Payload 跟 OpenAPI 定義的規格不符，Gateway 直接攔截報錯。

Issue Tracker 證據保全
在 GitLab 或 Jira 上面設定嚴格的 Webhook。任何 API 相關的 PR，Title 必須綁定 Ticket Number。如果發生事故，去撈 Ticket 的「建立時間」跟 PR 的「Merge 時間」。