Deprecation lifecycle 是 API 版本從宣告棄用到完全退場之間的一組執行工具，各自解決通訊鏈上不同的斷點，跟內部資料遷移使用的 Migration Gate 是同一類分階段收斂問題在不同邊界的應用——一個管內部資料能不能推進到下一階段，一個管外部消費者的退場節奏。宣告棄用本身容易，讓長尾消費者實際完成遷移才是工程問題，單一公告觸及不到所有消費者，這個生命週期因此需要多種工具組合，各自覆蓋不同的接觸面。

概念位置

執行工具箱有四種常見形態：分階段日期（先掐斷新增量、再處理存量，用不同時間點各擋一種風險）、in-band warning（在 response 內夾帶棄用警告，觸及率高於任何外部公告渠道，因為它出現在開發者一定會看的地方）、brownout（在正式停用前先短暫真實中斷，讓沒讀公告的長尾消費者在低風險時窗先遭遇明確失敗）、sunset header（用 HTTP header 宣告退場時點的機器可讀層）。跟 Feature Flag 常用於漸進開啟新功能相對，deprecation lifecycle 處理的是同一種漸進節奏在反方向的鏡像——漸進收斂舊功能。這組工具的組合邏輯是分層觸及：公告觸及會讀公告的人、in-band warning 觸及在開發的人、brownout 觸及所有人。

可觀察訊號與例子

Slack 收斂四族舊 API 到新版本時用三個日期各擋一種風險：宣告日起算，五個月後新建應用拿不到舊方法，十三個月後全面停用。先斷增量再清存量的順序讓債務停止成長，清理才有終點。GitHub 廢止密碼認證前，在兩個預告時窗暫時停用再恢復——這個 brownout 動作觸及的是完全沒讀過任何公告的長尾使用者。

判讀方式

判斷退場計畫是否完整，檢查前述三類消費者（讀公告的人、在開發的人、完全沒注意到的人）各被哪個工具覆蓋，任一類缺覆蓋就是通訊鏈的斷點。運作不良的訊號有三個：舊版呼叫量長期不衰減（工具箱沒有形成遷移壓力）、多數帳號卡死在首版（新版本的價值不足以驅動升級，或遷移成本被低估）、每次退場都演變成客訴事故（總有一類消費者始終沒被覆蓋）。三個訊號分別指向不同修法——執行工具、版本內容、通訊覆蓋——不該一律用延長支援期來回應。