Go 面試題：如何安全使用 Go 1.26 的 go fix 進行程式現代化遷移？
題幹與適用場景
一個包含多個模組、舊版建置約束與生成程式碼的 Go 儲存庫準備採用 Go 1.26。團隊想用 go fix 現代化程式碼，例如把暫時指標建構改成 new(expr)，但不能把新語法帶進仍需舊工具鏈編譯的模組，也不能把自動改寫當成正確性證明。你會如何拆分遷移、審查差異、測試與回滾？
這題考察工具鏈遷移與程式碼審查，不是背 release note。Go 1.26 官方說明指出，go fix 建立在與 go vet 相同的分析框架上，提供行為不變的現代化修正器；實際回答仍要說明版本門檻、生成流程、依賴與發布風險。
面試官考察點
高品質回答會先建立模組與版本矩陣，再選擇可解釋的小批次修正，接著用編譯、測試、靜態檢查與執行指標證明安全，最後保留可回滾邊界。普通回答只說「執行 go fix、跑測試、提交」，沒有說明哪些檔案可改、自動修正何時不該用，以及如何處理跨模組依賴。
面試官也會觀察你是否把 go fix 當成建議產生器，而非權限提升工具：工具能辨識程式碼模式，不知道隱藏的生成流程、反射約定、外部消費者或業務語義。
回答前需要釐清的問題
- 所有模組的最低 Go 版本是多少？ 低於 1.26 的模組不能接受依賴 1.26 語言特性的原始碼。
- 儲存庫是否包含生成程式碼或 vendored 程式碼？ 生成程式碼應修改生成器與產物策略，vendored 程式碼通常不應直接批次修改。
- 目標是語言現代化還是依賴升級？ 拆開處理可以縮小差異並獨立回滾。
- 有哪些行為敏感區域？ 序列化、反射、介面斷言、編譯標籤、cgo 與公開函式庫 API 需要額外審查。
- 如何驗證沒有破壞消費者？ 要確認單元、整合、競態、基準與下游相容性檢查，而不只是本儲存庫測試。
30 秒回答框架
可以說：「我先按模組記錄最低 Go 版本、生成來源與發布依賴，只讓符合 1.26 門檻的原始碼進入候選。先在一個小模組執行 go fix，保存補丁並人工審查，再執行格式化、編譯、測試、競態與基準檢查。通過後分批擴大範圍，保留舊分支與回滾點。對公開函式庫、反射與生成程式碼，我會改用手動或生成器遷移，再用下游建置與執行指標確認沒有語義變化。」
這段回答同時涵蓋限制、選擇、驗證與失敗路徑，避免把自動化命令當成結果。
分步驟深入解答
1. 建立版本與所有權矩陣
列出每個 go.mod 的 go 指令、工具鏈、發布方式、消費者與生成入口。Go 1.26 的 go fix 現代化修正器會依檔案所在模組的最低版本判斷是否適用；因此先升級模組宣告再批次改原始碼，會把相容性問題藏到更後面。
2. 將自動修正限制在可審查範圍
從一個模組或一個修正器開始，輸出補丁而不是直接覆蓋工作樹。排除 vendor、生成目錄與外部鏡像；生成程式碼要改生成器後重新生成。每批記錄修正器、檔案數、模組版本與預期語義。
3. 先理解一個代表性改寫
Go 1.26 允許 new 接受表達式來指定初始值，例如：
limit := new(64)它會建立指向初始值的指標，但只有模組語言版本允許該語法時才成立。遷移時要檢查泛型實例、常數型別推導、序列化指標語義與逃逸行為，不要把所有 new(T) 機械替換成 new(value)。
4. 執行分層驗證
每批至少執行格式化、編譯、單元測試、競態測試與靜態分析；公開函式庫再執行下游模組建置。效能敏感套件比較基準的吞吐、配置與延遲，反射或序列化套件增加真實樣本。驗證失敗時回到該批補丁，不要把所有自動變更一起合併。
5. 處理 go fix 不理解的邊界
工具無法證明執行時反射字串、程式碼生成模板、ABI 約定或外部消費者的語義。遇到這些區域，保留手動補丁並寫出不變量。例如序列化層要驗證 nil 與非 nil 指標輸出相同；公開 API 要比較匯出符號與文件，而不是只看本地編譯。
6. 設計發布與回滾
用獨立提交或 feature flag 分批發布；每批保留舊工具鏈建置與可回退產物。觀察錯誤率、啟動失敗、記憶體配置、基準回歸與下游建置失敗。一旦指標超過門檻，回滾最後一批，不要撤銷整個版本升級。
7. 形成可複用判斷規則
記住：版本先於語法，補丁先於批次，測試先於發布，生成器先於生成物，指標先於「看起來沒問題」。 go fix 適合減少機械工作，不適合取代模組治理與行為驗證。
高品質示範回答
「我會先盤點每個模組的最低 Go 版本、生成程式碼入口與下游消費者，把語言現代化與依賴升級拆開。對已允許 Go 1.26 的小模組，我執行 go fix 產生補丁，排除 vendor 與生成目錄，先人工檢查 new(expr)、泛型、反射與序列化邊界。接著執行 gofmt、建置、單元、競態、靜態分析與關鍵基準；公開函式庫還要建置一個舊版本消費者。每個批次獨立提交並保留舊產物。發布時分批觀察錯誤率、啟動失敗、配置與下游建置結果，超過門檻就回滾最後一批。生成程式碼則修改生成器再重新生成，不直接編輯產物。這樣自動化只負責機械改寫，正確性由版本矩陣、測試與執行證據共同證明。」
這個回答沒有聲稱工具能證明所有語義，也沒有把依賴升級、程式碼改寫與發布綁成一次不可逆操作。
常見錯誤
- 錯誤表現 → 在整個儲存庫直接執行 go fix → 失敗原因 → 混入舊模組、vendor 與生成物 → 修正方法 → 依模組版本與所有權建立候選範圍。
- 錯誤表現 → 只跑單元測試 → 失敗原因 → 忽略競態、效能與下游相容性 → 修正方法 → 為風險區域增加分層驗證。
- 錯誤表現 → 把
new(expr)當成所有指標建構的替代品 → 失敗原因 → 可能改變型別推導或 nil 語義 → 修正方法 → 逐類審查表達式型別與序列化結果。 - 錯誤表現 → 直接編輯生成程式碼 → 失敗原因 → 下次生成會覆蓋修正 → 修正方法 → 修改生成器並固定生成版本。
- 錯誤表現 → 一次提交全部自動變更 → 失敗原因 → 無法定位回歸與安全回滾 → 修正方法 → 每模組、每修正器獨立提交。
追問及應對
如果模組的 go 指令仍是 1.25，但建置工具是 1.26 呢？
區分工具鏈版本與語言版本：工具鏈可以較新，但模組原始碼能否使用 1.26 語法，取決於模組宣告與建置約束。先與維護者確認相容目標，再決定是否升級模組宣告與消費者矩陣。
自動修正後測試全綠，但序列化結果變了，你怎麼辦？
把序列化輸出當作相容性契約，先用舊產物與新產物對同一組樣本做位元組或結構比較，定位到具體改寫。若變化不被允許，回滾該批並改用手動遷移；若允許，更新契約、消費者與發布說明。
你如何證明生成程式碼沒有漏改？
在 CI 固定生成器版本，執行重新生成並檢查工作樹乾淨；將生成器原始碼、產物雜湊與建置版本關聯。評審生成器變更，不把手動編輯產物當成長期修正。
什麼時候不該使用 go fix？
當模組版本尚未確定、程式碼由外部生成、變更觸及公開 ABI 或缺少可執行驗證時，不應批次使用。先補齊所有權、相容性與測試證據，再選擇小範圍手動修改或暫緩遷移。