Go 1.26 newexpr 修复怎么落地：指针字面量替换与公共辅助函数兼容界线

项目里常见这样的结构：接口请求需要把可选数字编码成指针，于是代码到处出现 newInt(10)。Go 1.26 允许把表达式直接写进 new，同一类写法可以变成 new(10)；但这不等于看到辅助函数就直接删除。真正要看的是 fixer 是否覆盖了调用点、模块是否声明了正确版本，以及这个函数是不是稳定公共 API。

newexpr 先解决了哪类指针辅助函数

先把问题缩小。下面的 newInt 没有业务语义，只是把一个 int 表达式放进需要 *int 的位置：

type RequestJSON struct {
    URL      string
    Attempts *int `json:"attempts"`
}

func newInt(x int) *int { return &x }

payload := RequestJSON{URL: "/jobs", Attempts: newInt(10)}

Go 1.26 的 new 可以接收表达式，因此等价目标是 Attempts: new(10)。这里的关键不是“指针更快”，而是少一个只承担语法搬运的 helper；encoding/json 看到的仍然是 *int，字段为 nil 时的可选语义也没有被改写。

如果辅助函数里还有默认值、范围校验、日志、池化或单位转换，就不能把它当作 newexpr 的机械替换对象。先读函数体，再看调用方。

把 newInt 调用交给 go fix -newexpr

Go 1.26 重写了 go fix。针对这类迁移，可以限定 newexpr fixer，而不是让所有现代化建议一次改进：

go fix -newexpr -diff ./...
go fix -newexpr ./...

第一条只看 unified diff，适合放进提交前检查；确认补丁只涉及 newInt 的函数体和 RequestJSON 的 Attempts *int 调用点后，再执行第二条。官方说明还特别提到，生成文件不会被这类修复直接改写，应该回到生成器源头处理。

别急着把 diff 当成验收结论。重点看三件事：是否只改了允许升级的包，是否出现本地声明遮蔽 new 的调用，是否有依赖生成文件的目录被跳过。命令安静退出不代表每个 helper 都能删除。

为什么 go.mod 和构建约束决定改写范围

new(expr) 是 Go 1.26 的语言能力，fixer 不应把它写进仍需旧工具链编译的文件。官方 modernizer 的判断依据包括包所在 go.mod 的 go 1.26 指令，或文件上的 //go:build go1.26 约束。若模块只写着更低版本，先不要为了让补丁通过而抬高版本：这会改变构建基线。

这也是为什么同一个仓库里，有的 newInt 会被替换，有的不会。差异通常是版本边界，而不是 fixer 随机漏改。

公共 API 删除前如何做回归验收

如果 newInt 只在当前包内部使用，改写完成后可以用未引用检查确认它是否已经没有调用者；如果它是导出函数，删除就是 API 变更，不能因为仓库内搜索为零就直接删。外部模块、示例代码和旧版本分支都可能仍依赖它。

建议把验收拆成三个窄检查：先审 diff 和公开符号，再跑调用方回归测试，最后核对 RequestJSON 序列化后的 attempts 是否仍为数字、缺省指针是否仍按原规则处理。涉及库发布时，把 helper 保留一个兼容周期，通常比把升级压力转给调用者更稳。

可记录一条简单的提交检查：go fix -newexpr -diff ./... 生成的补丁可读，go test ./... 覆盖当前调用方，公开 API 清单没有未经讨论的删除。这样做的目标不是让代码看起来更短，而是让迁移责任有证据可追溯。

常见问题

newexpr 会不会把所有 &x 都改成 new(x)？

不会。它针对 newInt 类辅助函数和满足版本条件的安全替换，包含业务逻辑或公开兼容约束的函数仍需人工判断。

为什么 go fix -newexpr 没有改某个文件？

先查该文件所属模块的 go directive、构建标签、是否为生成文件，以及调用点是否存在本地 new 名称遮蔽。

改成 new(10) 后 JSON 会变化吗？

字段类型仍是 *int 时，正常序列化结果应保持同样的数字或 nil 语义；发布前仍应用现有序列化测试确认。

newexpr 的价值在于把重复的语法搬运交给工具，把版本和兼容决策留给维护者。先看 diff，再核对版本，最后用调用方和 JSON 行为收口，才是这次迁移真正可控的边界。