go fix ./... 静默退出之后：版本门槛、四个新 modernizer 和被默认关掉的那四个
项目信息：
- 官方博客：（Using go fix to modernize Go code, Alan Donovan）
- modernize 分析器文档：
- 发布说明：
现象：命令不报错，git 也是干净的
换了新工具链，按惯例在仓库根目录跑：
go fix ./...
退出码 0，没有任何输出，git status 一片干净。第一反应是"这仓库已经很现代了，没东西可改"。
实际上不是。go fix 只在源文件满足某个最低 Go 版本要求时才提供修复，版本门槛没跨过去，fixer 就安静地什么都不做。它不会告诉你"我看到了可以改的地方，但你的 go.mod 里 go 指令太低"。
根因：fixer 按文件的有效 Go 版本决定是否动手
为了避免提前引入新特性，modernizer 只会对"至少要求了相应最低 Go 版本"的文件给出修复。版本的判定有两条来源：外层 go.mod 里的 go 1.26 指令，或者文件自身的 //go:build go1.26 构建约束。
modernize 文档里写得很直白：
CutLast fixes are offered only when the file's Go version is at least 1.27.
也就是说，一个 go 1.25 的模块，即使工具链已经是新版，strings.CutLast 的替换建议也不会出现。同理，unsafefuncs 的源码里用 FileUsesGoVersion(Go1_17) 做门控，不满足时给出的提示是 unsafe.Add not available in this file。
分析框架为此提供了基础设施：可以查询一个文件"有效的 Go 版本"，由外层 go.mod 和构建标签共同决定，这样分析器就不会往文件里塞"太新"的用法。
所以升级工具链之后的第一件事，是把 go.mod 的 go 指令提上去，或者给需要提前使用的文件加 //go:build go1.x 约束。门槛不过，跑一百遍 go fix 也是静默的。
正确的调用方式
go fix 和 go build、go vet 一样接收包模式，./... 覆盖当前目录下所有包。成功时它直接改源文件，不打报告。默认它跑全部 analyzer。
先预览，别直接落盘：
go fix -diff ./...
列出可用的 fixer：
go tool fix help
加上某个分析器的名字，能看它完整的文档：
go tool fix help forvar
只想跑指定的分析器，用与名字相同的开关，比如 -any；想排除某个，取反即可，比如 -any=false。modernize 套件的文档建议分两步应用，便于 review：先只跑 any 并单独一个 commit，再跑其余的。
一次运行只分析一种构建配置。项目里按 CPU 或平台打了大量标签的文件时，换 GOOS/GOARCH 多跑几次：
GOOS=linux GOARCH=amd64 go fix ./...
GOOS=darwin GOARCH=arm64 go fix ./...
多跑几遍还能触发"协同修复"——前一遍的改动让后一遍的另一些修复变得可用。
如果某个 modernizer 是新版本才加进来或刚改过的，也可以脱离当前工具链单独跑：
go run golang.org/x/tools/go/analysis/passes/modernize/cmd/modernize@latest -fix ./...
四个新 modernizer 的替换规则
atomictypes：把 sync/atomic 调用里的基础类型换成原子类型。
var x int32
atomic.AddInt32(&x, 1)
变成：
var x atomic.Int32
x.Add(1)
原子类型更安全，因为它不允许非原子访问——这正是这类 bug 的常见来源；在 32 位架构上它还顺带解决了内存对齐问题。
embedlit：简化复合字面量中对嵌入字段的引用。新版本允许直接初始化从嵌入结构体提升上来的字段。给定：
type T struct { U }
type U struct { x int }
那么：
t := T{U: U{x: 1}}
变成：
t := T{x: 1}
slicesbackward：把反向遍历切片改成 slices.Backward。
for i := len(s) - 1; i >= 0; i-- { use(s[i]) }
变成：
for _, v := range slices.Backward(s) { use(v) }
如果下标在索引之外还有用途，下标和值都会保留：for i, v := range slices.Backward(s)。
unsafefuncs：通用形式是把 unsafe.Pointer(uintptr(ptr) + uintptr(n)) 换成 unsafe.Add(ptr, n)。源码里有 TODO，计划再支持 unsafe.String / StringData / Slice / SliceData。这个分析器由 FileUsesGoVersion(Go1_17) 门控。
顺带两条 release notes：fmtappendf 因为风格问题被移除；waitgroup 改名为 waitgroupgo。
默认关闭的四个，以及为什么
appendclipped（slices.Concat / slices.Clone）：默认关闭，因为该变换并非在所有情况下都保持 base 切片的 nilness，见 。它只在 append 塔的 base 是一个"clipped"切片时才应用，即 len == cap，比如 x[:0:0] 或 []T{}。
bloop（for b.Loop()）：省掉手动计时器控制，也顺带删掉 b.StartTimer / b.StopTimer / b.ResetTimer。问题是 b.Loop 的设计目标之一就是防止编译器把循环优化掉，这偶尔会让执行变慢，纳秒级 benchmark 的性能可能因此改变，所以 bloop 在 go fix 套件里默认关闭，见 。
fmtappendf（[]byte(fmt.Sprintf(...)) → fmt.Appendf）：这个修复不是帕累托改进，默认关闭，见 。到 1.27 干脆从 go fix 里彻底移除。
slicesdelete（s = append(s[:i], s[j:]...) → slices.Delete）：默认关闭，因为 slices.Delete 会把新长度到旧长度之间的元素清零以防内存泄漏，这是一处微妙的行为差异，见 。
文档里还有一批行为变化提示：minmax 会避开浮点类型（NaN 语义和 if/else 不同）；slicescontains 会改变目标表达式的副作用次数；omitzero 不会改动含 +kubebuilder 注解的包，而且把 omitempty 换成 omitzero 本身就是行为变化；mapsloop 用到的 maps.Clone 会保留 nilness，也可能产生细微差别；stringscut 对 Split(s, "")[0] 不提供修复；把循环替换成函数调用，可能丢掉循环内部的注释。
博客里还记了一个踩过的坑：他们做过一个把 append([]string{}, slice...) 换成 slices.Clone(slice) 的 modernizer，后来发现空切片时 Clone 返回 nil——一处细微的行为变化，极少数情况下会引发 bug，只好把这个 modernizer 排除掉。
modernize 文档对整体意图的表述是：修复可以安全地批量应用而不改变行为；但个别情况下修复并不完美，可能留下未使用的 import 或未使用的局部变量，导致编译失败，通常很好修。
冲突、生成文件与语义不一致
一次运行可能在同一个源文件里应用几十处修复。go fix 用的是简单的三方合并：如果某处修复与目前已累积的编辑列表冲突，这处修复被丢弃，工具会警告有修复被跳过、需要再跑一次。
语法冲突能可靠检出。麻烦的是语义冲突——两处改动在文本上互相独立，含义却不相容。典型例子是两个修复各自删掉了某个局部变量的倒数第二次使用，合起来这个变量就没人用了，直接编译错误。
因为未使用的 import 太常见，go fix 最后会单独过一遍，检测并自动删除未使用的 import。
至于生成文件，任何涉及生成文件的修复都会被丢弃，因为正确做法是改生成器本身的逻辑。
同一套版本模型带出的两处变化
go test 现在默认调用 stdversion vet 检查：当你用到的标准库符号比"当前文件生效的 Go 版本"更新时，它会报出来。生效版本的判定依旧来自 go.mod 的 go 指令和构建标签。这和 fixer 的版本门槛是同一个模型，只是一个管"能不能改"，一个管"能不能用"。
go mod tidy 对声明 go 1.27 及以上的模块，会自动合并重复的 require 块：最多保留两个 require 块，一个 direct 一个 indirect；注释块会保留；混合的注释块合并后挂到 direct 块上。此前那些互不相邻的多个 require 块（手工编辑、未解决的合并冲突、历史遗留升级留下的）会被原样留着。
另外，go doc 支持 package@version 语法，例如 go doc example.com/pkg@v1.2.3，并接受 -ex 列出可执行示例。GODEBUG 方面，go.mod 或 //go:debug 里已移除的设置如果被设成最终默认值，1.27 会接受；设成旧值则报错。
一份可照做的命令清单
# 1. 干净起点，改动只来自 go fix
git status --porcelain
# 2. 把 go.mod 的 go 指令提到目标版本，否则 fixer 静默
# 个别文件需要提前用时，在文件里加 //go:build go1.x
# 3. 先看帮助和单条规则
go tool fix help
go tool fix help forvar
# 4. 预览
go fix -diff ./...
# 5. 分批落盘：先 any 单独一个 commit
go fix -any ./...
git commit -am "go fix: any"
# 6. 再跑其余
go fix ./...
# 7. 多平台各跑一遍
GOOS=linux GOARCH=amd64 go fix ./...
GOOS=darwin GOARCH=arm64 go fix ./...
# 8. 跑到不动点，两遍通常够
go fix ./...
# 9. 验证
go build ./...
go test ./...
以上关于版本门槛、各 modernizer 的替换规则、默认关闭项及其 issue、以及 go test / go mod tidy 的行为变化，均来自官方博客、modernize 包文档与 1.27 发布说明；本地只做了单包级别的验证，未在完整仓库上跑过全量 go fix。