Go 1.26 的 go fix 怎么用：先看 modernizer 建议，再安全升级旧写法

项目升级到 Go 1.26 之后，最容易被大家忽略的变化不是新增语法本身，而是 go fix 终于有了比较完整的 modernizer 能力。它可以识别一批旧写法，给出基于 go/analysis 的改写建议；但它不是扫完整个仓库就直接覆盖代码的一键按钮。更稳妥的做法是先让它只检查一两个包，再对改动 diff、go.mod 版本和测试结果逐项确认。

把 go fix 当成可人工审查的迁移助手：先在 Go 1.26 模块里预览 modernizer 结果，再用小提交承接改动，最后用测试和静态检查确认业务行为完全没有变化。

Go 1.26 的 go fix 到底多了什么

以前的 go fix 更像一个早期遗留的历史工具，很多旧 fixer 已经没有太多现实使用价值。Go 1.26 重写了这条命令，新的实现建立在 go/analysis 之上，因此可以复用 go vet 的分析器模型，也能通过 modernizer 把代码逐步改成符合较新语言和标准库规范的写法。

一个很直观的例子是可选字段的指针初始化。旧代码常见的写法是先声明临时变量，再手动取地址：value := age; return &value。在 Go 1.26 中，new 可以直接接收表达式，目标写法可以简化成 return new(age)。价值不在于少写两行代码，而在于大型代码库可以由工具自动发现这类重复模式，再由开发者自行决定是否批量承接改动。

官方发布说明还提到，Go 1.26 的 go fix 包含数十个 modernizer，并支持通过 //go:fix inline 参与源代码级迁移。先弄清楚工具的适用边界，比一次性跑完整整个仓库要重要得多。

先准备一个能回滚的 Go 模块

为了看清版本门槛，准备一个最小测试模块。目录结构只保留 go.mod、业务代码和测试文件：mkdir gofix-lab && cd gofix-lab && go mod init example.com/gofix-lab。

如果命令由 Go 1.26 执行，新的 go.mod 默认可能写成 go 1.25.0，这是为了让新模块默认兼容仍受官方支持的旧版本。想使用 Go 1.26 的新写法，需要明确执行 go mod edit -go=1.26，然后单独提交这个变更。

生产项目不建议为了试验直接修改主分支。更安全的顺序是切出一个短生命周期的功能分支，先记录当前测试基准结果，再只调整 go.mod，确认依赖和 CI 镜像都能使用 Go 1.26 之后，才进入 modernizer 处理阶段。

用一个自定义 newInt 看懂 modernizer

很多旧项目不会直接写出可替换的临时变量，而是包了一层创建指针的辅助函数。下面的例子模拟一个早年用来快速生成基础类型指针的工具函数：

func newInt(value int) *int { result := value; return &result }
func DisplayAge(age int) string { pointer := newInt(age); if pointer == nil { return "unknown" }; return string(rune('0' + *pointer)) }

先执行测试和差异预览操作：

go test ./...
go fix -diff ./...

-diff 只展示改写建议，不会直接写入本地文件。终端里如果出现针对 newInt 的 modernizer 变更，先确认它只触碰了预期的目标包；如果没有输出，也不代表命令运行失败，有可能是版本门槛、代码模式或当前 fixer 范围不满足触发条件。

确认 diff 内容完全符合预期后，再执行会写回文件的命令，马上查看生成的改动：

go fix ./...
git diff --check
git diff --stat

如果 diff 中出现了业务逻辑、错误处理或公共 API 的非预期变化，直接终止这一轮操作。modernizer 的目标是安全做机械性改写，不是替你做架构层面的重构。

版本门槛和 CI 是最容易漏掉的地方

Go 1.26 的 modernizer 不会为了引入新语法破坏旧版本的兼容性。官方说明明确提到，相关修复通常只会在模块的 go.mod 声明了 go 1.26，或文件具备对应的 //go:build go1.26 约束时才会提供。刚运行完看到“没有建议”，不要立即判断代码没法完成升级。

可以把一次迁移的检查点收敛成下面这张表：

什么时候应该接受，什么时候应该回退

如果改动只是在同一函数内用 new(expr) 替换临时变量，diff 改动量很小、测试覆盖充分，通常可以直接接受。若改动跨越公共依赖包、生成代码或带 build tag 的平台专属实现，更建议拆成多个独立提交，分别在 Linux、macOS 和 CI 环境上跑完验证。

回退操作也很简单：不要把工具自动输出的改动混进手工重构的提交里，先把 modernizer 生成的改动单独提交。发现兼容问题时，可以直接回退这一个提交，保留已经确认过的 go.mod 升级或其他独立变更。

go test ./...
go vet ./...
go list -m all >/tmp/gofix-modules.txt
git diff --check

go list -m all 用来确认整个项目的依赖图仍然可以正常解析；如果 CI 环境还停留在 Go 1.25，先不要把只在 Go 1.26 下能运行的语法合并到默认构建路径。工具可以帮你批量改写代码，但版本兼容策略仍然要由项目维护者自行决定。

相关问题

go fix 会不会像格式化工具一样改完整个仓库？

它按分析器和包范围工作，不是全量重排代码的格式化器。第一次使用应先跑带 -diff 的预览命令，再决定是否执行写回操作。

go fix 和 gofmt 是一回事吗？

不是。gofmt 负责统一代码排版风格，go fix 负责基于代码语义提出或应用修复；两者可以连续使用，但职责完全不同。

go.mod 还是 go 1.25，能不能直接使用 new 表达式？

不建议。先确认项目的最低支持版本，再把语言版本、编译镜像和 CI 配套一起升级，否则本地能编译并不代表发布整条链路都能正常编译。

modernizer 没有输出是不是失败了？

不一定。检查 Go 版本、模块语言版本、目标代码是否命中当前 fixer，再用 go test 和 go vet 判断工具链是否运行正常。

把自动改写变成一次可审查的升级

Go 1.26 的 go fix 值得尝试，但适合放进“预览、审查、回归、可回退”的小流程里运行。先用官方 modernizer 找出所有机械性改写，再通过代码评审决定哪些变化真的提升了代码可读性；明确保留版本门槛和测试验证证据，升级才不会变成一次难以定位问题的全仓库大 diff。