Go fix inline 遇到变量遮蔽时怎样保持求值顺序

使用 //go:fix inline 做 API 迁移时，最容易误解的是“内联就是把函数体粘贴到调用点”。实际的 go fix inline 分析器还要保护两个语义：调用方表达式原来绑定的名字不能被函数体的局部变量遮住，参数和函数体中其他调用产生的副作用也不能被随意换序。因此，它宁可插入显式的局部绑定，也不会为了短几行代码牺牲原来的求值关系。

遇到变量遮蔽时，先把调用方参数读入一个不会被遮蔽的绑定；遇到可能改变副作用顺序时，也用显式绑定保留顺序。迁移前用 go fix -inline -diff ./... 看补丁，迁移后照常 review、构建和测试。

变量遮蔽为什么不能只做文本替换

假设一个函数的参数名是 val，函数体又声明了局部变量 x：

//go:fix inline
func show(val string) {
    x := 123 // 中文注释：这是被内联函数内部的新名字
    fmt.Println(val, x) // 中文注释：val 应该仍指向调用方传入的字符串
}

x := "hello"
show(x) // 中文注释：调用方的 x 在调用前求值

如果把函数体直接塞到调用点，调用方的 x 可能和函数体里的 x 落在同一个作用域，名字含义就变了。安全的改写会先读取调用方的值，再进入局部变量的作用域：

x := "hello"
{
    var val string = x // 中文注释：先保存调用方 x，避免后面的局部 x 遮蔽它
    x := 123 // 中文注释：保留原函数体的局部变量
    fmt.Println(val, x) // 中文注释：分别使用调用方参数和函数体局部值
}

这里的 var val string = x 不是多余代码，而是名称绑定的保护层。它让 val 继续代表调用方的 x，也让函数体中的 x 保持原来的局部含义。Go 官方对 source-level inliner 的说明把这种处理称为 parameter binding；如果被内联函数引用了调用方中不存在的名字，还可能需要补充导入。

求值顺序为什么会逼出临时变量

名称遮蔽之外，参数表达式本身也可能有副作用。下面的函数故意反转了参数在函数体中的使用顺序：

//go:fix inline
func add(x, y int) int {
    return y + x // 中文注释：函数体先使用 y，再使用 x
}

z = add(f(), g()) // 中文注释：调用参数按调用表达式的顺序求值

如果直接替换成 z = g() + f()，就可能让 g 先于 f 发生效果。比如两个函数都会写共享状态、记录日志或从通道收发时，结果不再等价。更稳妥的改写是：

var x = f() // 中文注释：先固定第一个实参的求值结果
z = g() + x // 中文注释：再执行第二个实参，并保留函数体中的计算关系

Go 规范规定，表达式中的函数调用等事件遵循相应的词法从左到右规则；而 source-level inliner 还要考虑参数与函数体其他代码的相对位置。如果函数体把参数放进循环，替换还可能改变某个副作用发生的次数。所以即使人眼看起来“只是换了个位置”，工具也可能选择保守地生成绑定。

用 go fix -inline 预览，再决定是否应用

在 Go 1.26 的新式 go fix 中，inline 是按 //go:fix inline 指令工作的分析器。先只看补丁：

# 中文注释：只预览 inline 分析器将要修改的补丁
go fix -inline -diff ./...

# 中文注释：确认补丁后，才把修复写回源码
go fix -inline ./...

预览时重点看三类变化：是否新增了绑定变量；绑定是否放在原调用参数应有的位置；是否出现了额外导入、未使用变量或超出迁移边界的改动。不要把 go fix 的静默成功当成行为等价证明，它只是说明分析器接受了这次源代码改写。

迁移后的 review 清单

把补丁放进正常的代码审查流程即可，建议按下面顺序收尾：

# 中文注释：先确认只改了预期文件和调用点
git diff --stat
git diff

# 中文注释：检查格式、编译和测试，发现绑定导致的未使用变量要立即处理
gofmt -w ./path/to/changed.go
go test ./...

• 如果看到 var 绑定，先确认它保存的是调用方表达式，而不是被遮蔽后的局部名字。
• 如果函数参数包含函数调用、通道收发或写状态操作，不要自行把工具生成的绑定合并回一行。
• 如果迁移结果出现未使用的调用方变量，按官方说明人工清理或缩小迁移范围；这属于源代码整理，不要为了追求短代码删除必要的求值。
• 如果结果过于保守，先保留可读的安全版本，再单独提交手工重构，方便 review 和回滚。

相关问题

go fix -inline 会处理所有函数吗？

不会。它针对带 //go:fix inline 指令的函数、常量或类型别名引用运行 inline 修复；普通函数不会因为名字短就被批量改写。

为什么编译器能优化，源码内联器却更保守？

编译器优化的是某一次构建得到的机器码，源码内联会留下长期存在的文本。源码之后可能被修改，因此工具不能依赖今天才成立的“没有副作用”事实。