中小企何時可以安全移除功能旗標？

功能推出後仍有第二項工作

功能旗標可讓團隊在執行期間選擇不同程式路徑，但每次評估旗標都多了一個決定。當新功能已成為預期的標準體驗，舊條件判斷可能仍藏在網站、背景工作、手機程式或共用程式庫。移除旗標意味著選定永久行為、刪除過時分支，並在移除設定前檢查各個環境。LaunchDarkly 的封存文件明確要求先移除程式碼引用，因為封存後仍被查詢的旗標可回傳程式中定義的備用值。這是該供應商的特定行為，也說明一個普遍道理：把旗標對所有人開啟，並不等於已安全移除。

這個問題與「網站改版如何上線」不同。改版可能早已成功，餘下風險是隱藏的舊分支意外被執行，或刪除共用旗標時改變了未被注意的流程。每個臨時旗標都應有負責人、用途及預定覆核時點。不應虛構所有旗標通用的到期日，因為營運保護開關與短期推出旗標存在理由不同。Microsoft 的功能管理指引把簡單開關、分階段推出及實驗分開處理。決定移除時，先確認此旗標目前真正扮演甚麼角色；長期保護控制與已完成的推出開關，維護方式可以不同。

明確定義何謂已完成

旗標儀表板顯示某一個版本已開啟，並不足以證明可以刪除。應檢查真正受影響的對象和環境：正式網站、背景工作、內部工具、定時任務，以及仍可能在使用的舊版客戶端。若新功能應提供給所有合資格顧客，須確認排除名單、地區規則或個別帳戶覆蓋設定是否仍有業務原因。OpenFeature 的評估情境規格指出，目標對象可由使用者識別鍵、語言地區或機構成員身分等資料決定。因此看似全域的百分比或預設值，未必涵蓋完整規則。把預期的永久行為寫成產品負責人能審閱的文字。

查核使用情況時，不能把缺乏遙測當作「沒有人使用」的證明。評估紀錄、設定歷史及程式碼搜尋可以指出仍在使用旗標的地方，但各有盲點。每月才執行一次的工作，在短期觀察中可能完全不出現；執行時才組合出的鍵名，也可能避開簡單文字搜尋。可行時，把執行觀察、程式庫搜尋、部署清單及流程負責人的資訊合併檢視。若沒有可信的量度，應如實說明，並直接測試懷疑仍會使用旗標的路徑。驗收重點是：所有可能影響顧客或營運決定的地方，永久分支是否仍正確運作。

修改前先找齊依賴

應在應用程式、測試、基建設定、版面範本及操作腳本中搜尋旗標鍵名；若曾改名，也要包括別名。除了評估旗標的呼叫，還要找出各個回傳值帶來甚麼行為：路由、按鈕、資料欄位、背景動作或第三方請求。LaunchDarkly 有文件說明如何用程式碼引用工具找鍵名，但該工具是否可用取決於客戶方案，而且掃描工具仍須能在程式中辨識該鍵。未使用該服務的團隊，也可有系統地搜尋並列出受影響元件。目標是理解行為，不是收集一長串文字命中結果。

程式碼與設定要分開盤點。同一旗標在開發、測試及正式環境可能有不同目標規則，共用專案又可能讓多個環境使用相同旗標。LaunchDarkly 提醒，封存旗標會從專案的所有環境移除。因此看似局部的清理，可能影響仍在使用同一鍵名的測試流程或另一個應用。應確認每個環境的負責人，以及其他旗標是否依賴此旗標作先決條件。若團隊無法解釋某一處引用，應先調查或安全隔離，再完成移除。為了讓儀表板整齊而刪掉未知設定，並非充分的業務理由。

用單一清楚路徑取代條件判斷

程式修改應令選定分支成為無條件流程、移除過時分支，同時保留重要的業務驗證。不要只把旗標評估改成固定 true，卻留下舊程式路徑；死碼會令日後維護者誤以為它仍有用途。測試也要同步整理：只為舊版本存在的測試可移除，但顧客結果、授權、資料寫入及錯誤處理仍須有驗證。若舊分支曾以不同格式寫入資料，還要檢查既有紀錄及下游讀取程序在清理後仍可理解。

可先保留旗標設定，部署移除條件判斷後的程式，再按該應用的一般上線檢查觀察是否仍有已部署元件查詢舊鍵名。這是一個較安全的建議次序，不保證所有供應商語義完全相同。應確認仍在運作的程式版本，尤其是不能即時更新的手機客戶端或延遲背景工作。只有相關程式路徑都已更新及檢查，才按供應商的規則封存或移除設定。服務復原仍須依正常部署流程；已淘汰的舊分支不應長期充當回退方案。

以預約提醒功能為例

假設一家服務公司曾用旗標在舊電郵提醒與新提醒流程之間選擇。新流程已成為合資格預約的預期做法。團隊發現旗標同時存在於預約網站、定時寄送程式及內部預覽工具；只看網站便會漏掉兩處。負責人把永久規則寫清楚：合資格預約使用新提醒，不合資格的預約不寄提醒，而顧客看到的確認內容保持準確。這只是示範情境的規則，並非對任何真實公司的系統或法律通知義務作出聲稱。

團隊測試一般預約、不合資格預約、已取消預約，以及寄送程序重試，確認新流程不會重複寄信，內部預覽亦與實際規則一致。之後在各元件移除舊路徑程式碼、部署更新，並確認所有仍運作的背景工作已換成新版本。若舊手機程式仍會查詢旗標，任務便未完成，須先處理該版本。沒有相關引用，並核實供應商的行為後，才封存或移除設定。這個次序的價值在於明確的完成證據，而不是讓開關保持開啟若干個武斷天數。

用證據完成清理

簡短的移除紀錄應列出旗標、負責人、選定的永久行為、受影響元件與環境、測試結果，以及最後對設定採取的動作。連到程式修改，並註明若另有目的而刻意保留的營運開關。若供應商封存後會回傳備用值，應記錄該值，以及為何已沒有仍在使用的客戶端依賴它。不要只因短期內沒有觀察到評估事件，就推斷已安全。日後維護者應能從紀錄理解舊路徑為何消失，以及現行業務規則所在。

若仍有依賴，就如實記錄部分完成：某個元件的程式清理或許已準備好，但旗標本身仍不能封存。應指出阻礙、負責人及下一項測試，並繼續受控地保留設定。證據不足時暫緩移除，是正確的業務決定。對小團隊而言，定期簡要檢視臨時旗標，可避免過時分支累積。每次都問：這個旗標現在是否仍會改變真實決定？負責人是否仍知道原因？需要甚麼證據才能最終移除？

若旗標曾控制的不只是畫面，舊資料路徑要另作決定。曾經選擇價格計算、通知佇列或紀錄格式的旗標，即使所有現有顧客都看到新體驗，也可能留下仍須讀取的舊資料。應盤點舊分支建立了甚麼、誰仍會使用，以及歷史紀錄是否須保持可讀。只有選定路徑能正確處理那些紀錄，或經過測試的資料遷移已完成，才刪除條件判斷。若舊分支原本是外部依賴的安全控制，移除前要決定是否需要另一個營運開關。程式碼搜尋及儀表板狀態只是調查起點，並非完整的移除決定；持久資料的影響可能比旗標查詢留得更久。