Go1.26で生まれ変わったgo-fixをプロダクト開発に乗せる¶
チェック¶
- [ ] 本文を確認した
- [ ] 概要を確認した
- [ ] タグを確認した
- [ ]
inbox/直下へ移行した
概要¶
Go 1.26 で modernize analyzer が組み込まれ、go fix が実用的な code modernization tool として復活したことをプロダクト開発でどう運用するかの資料。
interface{} から any、loop から slices.Contains、wg.Go、min / max、strings.Cut などの変換 rule が紹介されている。
導入では、既存 code を一括変換し、普段は golangci-lint の modernize linter で検知する運用が提案されている。
本文¶
go fix は Go 1.0 では API 変更の自動 migration tool として登場したが、Go 1.1 から 1.25 までは rule があまり追加されず、ほぼ使われていなかった。
Go 1.26 では modernize analyzer が組み込まれ、24 rule に沿って安全に code を modernize できるようになった。
2026-02-21 時点で 20 rule が default 有効とされる。
例として、次のような変換がある。
interface{}→any- loop による要素探索 →
slices.Contains wg.Add(1)+go func+defer wg.Done()→wg.Go- if / else の比較 →
min()/max() - map copy loop →
maps.Copy strings.Index+ slice →strings.Cutsort.Slice→slices.Sortcontext.WithCancel(context.Background())→t.Context()
一部 rule は default 無効。
appendclipped は nil slice の挙動差、bloop は benchmark hang、slicesdelete は zero clear による panic など、挙動不一致や問題があるため慎重に扱う。
実プロダクトでは、49 files、218 箇所の変更が行われ、既存 test / lint / integration test はすべて pass したとされる。
go fix は 2 回実行が推奨される場合があり、1 回目の修正が 2 回目の修正機会を作ることがある。
運用としては、既存 code には go fix ./... を一括適用し、CI では検知を常時 ON にする。
golangci-lint v2 を使っているなら modernize linter を有効化する。
go fix による自動書き換えは Go version 更新時に行い、普段は検知に任せる。
要点¶
- Go 1.26 の
go fixは modernize analyzer により実用性が上がった。 - 一括適用と日常検知は分けて考える。
- golangci-lint modernize は既存 CI に統合しやすい。
- Default 無効 rule は挙動差の理由を理解してから使う。
- 自作 analyzer に SuggestedFix を足すと fix tool にできる。