Go 1.26 new(expr) 怎么用：给可选字段赋指针值时的收益与兼容边界

给 JSON 请求补一个可选整数时，旧写法往往要先声明变量，再把地址塞进结构体。Go 1.26 允许 new 接收表达式，new(42) 直接得到一个值为 42 的 *int，这让“值存在还是缺省”这类代码短了一截，但也把最低 Go 版本抬到了 1.26。

Go 1.26 的 new(expr) 到底改变了什么

过去的 new(T) 只能写类型，结果是一个指向零值的指针。Go 1.26 放宽后，操作数可以是表达式，返回值类型是指向该表达式类型的指针。例如：

age := new(18)
fmt.Println(*age) // 18

它本质上不是把普通变量的地址运算符做了一层隐藏，而是创建全新的变量来存储表达式的执行结果。整个表达式只会被求值一次，返回的指针指向的存储区域完全独立于之前的临时计算过程。

用一句话判断是否值得改：如果代码只是为了给结构体字面量制造一个带初值的指针，new(expr) 通常更直接；如果变量还要被多次修改、复用或需要明显的命名，原来的声明方式更容易读。

可选字段为什么是最自然的落点

JSON 中的数字字段常用 *int 区分“没有传”与“传了 0”。旧写法需要额外变量：

age := 18
person := Person{Name: "Lin", Age: &age}

Go 1.26 推出这个能力之后，我们就可以直接把对应的赋值意图写在结构体字面量里，不用额外拆分临时变量：

type Person struct {
    Name string `json:"name"`
    Age  *int   `json:"age,omitempty"`
}

person := Person{
    Name: "Lin",
    Age:  new(18),
}

当 Age 是 nil 时，omitempty 可以省略字段；当它指向 0 时，字段仍然存在。这个差异才是指针的价值，不能因为写法变短就把所有字段都改成指针。

先核对序列化结果，再谈代码变短

body, err := json.Marshal(Person{Name: "Lin", Age: new(0)})
if err != nil {
    panic(err)
}
fmt.Println(string(body)) // {"name":"Lin","age":0}

body, _ = json.Marshal(Person{Name: "Lin"})
fmt.Println(string(body)) // {"name":"Lin"}

验收点只有两个：new(0) 的结果必须包含 age:0，而缺省的 nil 必须省略。接口协议若把这两种状态当成不同命令，测试不能只检查反序列化后字段值。

这项变化对哪些项目有实际收益

从实际落地的情况看，Go 1.26 直接砍掉了语言表达式和「可选值指针」之间重复的胶水代码，收益最明显的覆盖三类高频开发场景：

• API 客户端开发：构造 PATCH 请求时，经常需要同时表达“更新为 0”和“完全不更新该字段”两种语义，用新语法写起来更直观。
• 协议适配层：把外部消息映射到内部结构体时，多个字段都需要保留字段是否存在的状态，不用再额外定义一堆局部变量。
• 测试代码：写表驱动测试的时候，可以就地声明不同的指针初值，省去大量零散的临时变量定义。

收益不会自动变成性能收益。这里主要改善的是可读性和局部表达能力；是否分配到堆上仍由编译器逃逸分析决定，不能把 new(expr) 解释成“强制堆分配”或“必然更快”。

兼容边界：库升级前先看三处版本

这项语法的代价是编译器门槛。Go 1.25 或更早的工具链无法解析 new(18) 这种写法，所以公共库要先检查：

如果你的项目还需要继续支持 Go 1.25，继续用旧写法完全没有问题。可以把指针生成逻辑收进一个命名清晰的小工具函数，或者保留原来的临时变量写法，不用为了追求一行代码的简洁，把整个依赖树的最低版本要求一起拉高。

从旧写法迁移时怎样做一轮可回滚验证

1. 先用 go version、go env GOTOOLCHAIN 记录实际工具链，并确认仓库的兼容承诺。
2. 只替换结构体字面量中的指针初值，保持原有 JSON 标签、字段类型和业务默认值的逻辑完全不变。
3. 为非空、显式零值和 nil 各保留一个序列化测试。
4. 跑完所有现有测试；如果是公共库，额外用声明支持的最低 Go 版本再跑一轮全量编译测试。

go version
go test ./...
go list -m -json | grep -E 'Path|GoVersion'

如果项目的最低支持版本还没准备好，不要在正在维护的兼容分支里偷偷用新语法。把迁移动作安排在明确的版本迭代节点上，发布说明里标注清楚“需要 Go 1.26 及以上版本”，后续如果要回滚也只需要把新语法换回原来的临时变量写法，同步调整对应测试即可，不会影响上层的协议字段逻辑。

常见问题：new(expr) 的几个判断题

new(18) 和 &age 是完全一样的吗？

最终都能得到一个指向整数的指针，但 new(18) 直接创建并初始化新变量，&age 取的是已有变量地址。后者适合变量还要参与后续逻辑的场景。

可以写 new(time.Now()) 吗？

只要传入的表达式类型和指针指向的类型匹配合法，就可以直接把表达式作为 new(expr) 的初值。不过涉及时间生成、随机数或者自带副作用的调用，最好还是先赋值给命名变量再传，便于后续测试和逻辑复用，代码行数少不等于代码意图就更清晰。

使用 new(expr) 会让指针一定逃逸吗？

不会。是否逃逸由编译器根据使用方式决定，不能只凭 new 的写法下结论。需要时用编译器的逃逸分析观察实际结果。

Go 1.25 项目能否只通过 go.mod 声明来使用它？

不能。语法由编译器解析，项目必须使用支持该语法的 Go 1.26 工具链；修改 go.mod 不能让旧编译器认识新语法。

采用建议

new(expr) 是一个小而实用的表达能力增强，最适合可选字段、测试夹具和协议映射中的局部初始化。先确认版本承诺，再用序列化测试守住 nil 与显式零值的区别；能让读者少追一个临时变量，就迁移，不能就保留旧写法。这样获得的是更清楚的代码，而不是一场为了新语法的全仓库改造。