Go 1.26 的 new 为什么能直接写表达式？旧项目要不要改

平时给JSON结构里的可选数字字段赋值时，旧版Go往往得先声明一个临时变量，再把它的地址放进结构体。Go 1.26放宽了内置 new 的参数规则，现在可以直接写 new(42)，得到一个指向初始值42的 *int。这个变化主要改善指针字段的表达方式，不会让旧代码失效，也不值得为了“看起来新”就全量改写。

新写法适合一次性构造带初始值的指针，旧项目先确认构建工具链和模块版本，再在局部代码中迁移；不要把它当成必须完成的升级任务。

Go 1.26 到底改变了 new 的哪条规则

以前的 new(T) 只能把类型放进括号里，结果是一个指向零值的指针。要创建一个带具体值的指针，通常要先单独声明变量：

age := 18
person := Person{Age: &age}

Go 1.26 允许括号里出现表达式，表达式运行后的结果就是新分配变量的初始值：

person := Person{Age: new(18)}
fmt.Println(*person.Age) // 18

这里的 new(18) 推导出 *int。如果表达式是 int64(18)，得到的就是 *int64。它仍然会分配一个独立变量，修改指针指向的值不会改动原表达式里的临时结果。

JSON 可选字段为什么最先受益

不少接口结构会用指针区分“字段完全没出现在入参里”和“字段明确传了零值”两种场景。比如年龄字段缺失时要保持 nil，年龄明确为0时则需要保存一个非空指针。旧写法可读性不算差，但在构造测试数据或者小型转换函数时，会多出很多只用一次的临时变量。

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

func makePerson(name string, age int) Person {
    return Person{Name: name, Age: new(age)}
}

序列化结果仍由 encoding/json 的规则决定：指针非空就会输出对应字段，指针为空才会因为 omitempty 被省略。new 只负责构造指针，完全不会改变JSON标签、字段名或者空值判断逻辑。

这也解释了为什么不建议把所有 &value 都换成 new(value)。如果变量后面还要被多处修改，保留变量名更容易体现状态变化；如果只是把一个计算结果直接塞进结构体，直接写表达式会更清爽。

泛型场景变了，但不是每段代码都要重写

Go 1.26 还放宽了泛型类型参数列表的自引用限制。这个变化面向类型约束和抽象数据结构，和 new 的语法改动是完全独立的两件事。普通业务代码如果没有自定义递归约束，完全不需要因为版本升级调整类型声明。

type Adder[A Adder[A]] interface {
    Add(A) A
}

func sum[A Adder[A]](left, right A) A {
    return left.Add(right)
}

迁移的时候要把“语言现在支持什么语法”和“项目本身是否需要这个能力”分开判断。新规则只是扩大了可表达的范围，不等于旧接口要改签名，也不等于强行引入泛型后代码一定更清晰。先看调用方和约束是不是真的能减少重复代码，再决定要不要改。

旧项目升级时先看 go.mod 和工具链

Go 1.26 的新写法必须由能识别该语法的工具链构建。先核对模块声明和当前在用的工具链：

go version
grep '^go ' go.mod
go env GOTOOLCHAIN

新建模块时，Go 1.26 的 go mod init 默认会写入更低的兼容版本，目的是让模块继续覆盖之前受支持的旧版本。这个默认值不代表当前代码可以直接用所有新语法；真正提交 new(表达式) 前，要在项目要求的最低构建环境里跑一次完整检查。

如果仓库还是用Go 1.25或者更早的固定镜像构建，直接提交新写法会在编译阶段直接报错。此时有两个稳妥选择：暂时继续用旧写法，或者先升级CI镜像、开发容器和发布机，再单独提交语法迁移。别只在自己本地电脑上跑通就直接合并。

用三道检查决定是否迁移

可以把一次局部迁移压缩成下面三步。第一步确认工具链版本，第二步确认行为没有变化，第三步确认团队里的旧构建入口也能识别结果。

1. 编译检查：在项目声明的最低支持工具链上运行 go test ./...，确认没有语法或类型错误。
2. 行为检查：为指针字段补上空值、零值和普通值三类测试，确认JSON输出和迁移前完全一致。
3. 环境检查：在CI、容器构建和本地开发脚本中分别打印 go version，避免某个隐藏入口还在使用旧版本。

如果只是为了少写一行临时变量，第三步检查发现项目升级工具链的成本很高，那就先不迁移。Go的兼容承诺保护的是已经写好的旧代码，团队自己的构建链路才是新语法能不能落地的实际边界。

常见问题

new(42) 返回的是什么类型？

它返回指向初始值的指针，字面量42在没有其他上下文时会推导为 *int；使用显式类型转换可以得到 *int64 等其他指针类型。

Go 1.25 能编译 new(表达式) 吗？

不能把它当作Go 1.25兼容语法使用。项目如果还需要用Go 1.25构建，就继续保留临时变量写法，或者先升级所有固定工具链。

用 new 创建指针会改变 JSON 的 omitempty 行为吗？

不会。非空指针仍会参与序列化，空指针才会按 omitempty 规则省略；变化只在指针的构造方式上。

旧项目应该一次性替换所有指针写法吗？

不建议。优先改一次性构造的DTO、测试夹具和转换函数；对需要持续修改的变量保留旧写法，代码意图通常会更清晰。

把新语法用在真正减少噪音的地方

Go 1.26 的 new 表达式是一个小而实用的语法补丁：它让“把一个确定值包装成指针”的过程变得直接，尤其适合可选字段和短小构造函数。迁移前先确认最低工具链，迁移后检查JSON行为和CI环境；这三件事比追求全仓库统一写法更重要。