Go 1.26 的 new(初始值)怎么用：JSON 可选字段不再单独声明临时变量

开发接口时常碰到一个容易忽略的小需求：调用方明确传了 false 或 0，返回的响应 JSON 里也必须原封不动保留这个值。不少项目为了实现效果把对应字段设为指针类型，构造结构体之前要零散声明好几个临时变量。Go 1.26 给 new 新增了直接用表达式初始化的写法，刚好能把这部分重复的样板代码收拢到结构体字面量里。

这个小改动要解决什么实际问题

假设我们正在写一个通知偏好配置接口。Marketing 标记用户是否接收营销推送，Retry 标记调用失败后的重试次数；两个字段都需要明确区分「调用方完全没设置」和「调用方主动设置为 false 或 0」这两种情况。直接用普通值类型定义 bool、int 很难保留这种区分逻辑，换成指针类型实现起来会自然很多。

package preference

type Preference struct {
	Name      string `json:"name"`
	Marketing *bool  `json:"marketing,omitempty"`
	Retry     *int   `json:"retry,omitempty"`
}

这里不用急着追求写更短的代码，先确认当前模块的构建基线确实可以用 Go 1.26 及以上的语言版本。直接把新语法放到仍要兼容旧工具链的公共库里，会导致下游项目直接编译失败。

先把语言版本约束写进 go.mod 再改代码

先搭好最小可运行项目。如果整个模块已经确定全局采用 Go 1.26，这个版本要求要在 go.mod 里明确声明，不能只靠个别开发者本地装的新版编译器来跑。

module example.com/optional-preference

go 1.26

接下来新建 preference.go 和对应的测试文件。只需要确认一个核心点：团队的 CI 流水线、构建镜像、所有开发人员的本地工具链都能正常用 Go 1.26 完成这个模块的编译。官方配套的各类工具也会把 go.mod 里声明的语言版本作为启用新特性的前置判断条件，不会看到新版编译器就自动替换所有旧写法。

旧写法为什么很容易把构造逻辑拉得很长

在 Go 1.25 以及更早的语言版本里，想要拿到一个带指定初始值的指针，常规做法是先声明局部变量赋值，再对变量取地址。逻辑本身没有问题，只是后续新增的可选字段多了之后，构造代码里会塞满各种只用来取地址的临时变量。

func defaultPreferenceOld() Preference {
	marketing := false
	retry := 3

	return Preference{
		Name:      "Mina",
		Marketing: &marketing,
		Retry:     &retry,
	}
}

这段代码的风险根本不是取地址操作本身，而是后续维护成本会变高：字段多了之后，临时变量定义和最终结构体赋值的位置隔了好几行，阅读代码的人要反复来回对照。对于这种只在当前位置出现一次的固定默认值，更合理的写法是把初始化逻辑直接贴在对应的结构体字段旁边。

Go 1.26 可以直接把默认值写进结构体字面量

接下来就可以动手改代码了。Go 1.26 的 new 现在支持直接接收一个表达式作为入参，返回的就是指向这个初始值的指针。对应到这个业务场景，构造函数可以直接写成下面的样子。

func defaultPreference() Preference {
	return Preference{
		Name:      "Mina",
		Marketing: new(false),
		Retry:     new(3),
	}
}

判断逻辑非常直白：new(false) 不是空指针，它明确代表「这个字段存在，值就是 false」；new(3) 的语义也完全一致。这个新特性没有改动 JSON 序列化的原有规则，只是把之前需要两步完成的指针初始化逻辑合并成了一行表达式。

写测试确认 false 和 0 没有被意外丢弃

这种小改动最不能省的就是行为测试。不能只看代码编译能不能过，还要实际验证可选字段确实会被输出到最终的 JSON 里。下面的测试用例特意取 false 和 0 作为校验值，避免刚好取到默认真值把指针的语义差异掩盖过去。

package preference

import (
	"encoding/json"
	"testing"
)

func TestOptionalValuesStayVisible(t *testing.T) {
	p := Preference{
		Name:      "Mina",
		Marketing: new(false),
		Retry:     new(0),
	}

	data, err := json.Marshal(p)
	if err != nil {
		t.Fatal(err)
	}

	want := `{"name":"Mina","marketing":false,"retry":0}`
	if string(data) != want {
		t.Fatalf("got %s, want %s", data, want)
	}
}

在 Go 1.26 环境下跑完 go test ./... 之后，所有测试都应该正常通过。如果把 Marketing 或者 Retry 改成 nil，对应带 omitempty 标签的字段就会被序列化逻辑自动省略，这正是指针类型在这个数据结构里承担的区分能力。

还在兼容旧版本的项目别强行塞新语法

如果当前模块还要支持 Go 1.25 或者更老的版本编译，直接到处写 new(false) 不属于平滑的渐进升级。更稳妥的做法是保留一个非常轻量的辅助函数，等全链路最低版本统一升级完之后再逐步迁移。这样调用位置的语义也足够清晰，不会在发布环节出现意料之外的语言版本兼容问题。

func boolPtr(v bool) *bool { return &v }
func intPtr(v int) *int    { return &v }

func defaultPreferenceCompatible() Preference {
	return Preference{
		Name:      "Mina",
		Marketing: boolPtr(false),
		Retry:     intPtr(3),
	}
}

这里要避开一个常见误区：不要为了用新写法，单独把 go.mod 的版本号拉高，却忘了同步更新 CI 镜像、容器构建流程或是下游依赖库的版本约束。升级语言版本要和全链路的工具链更新同步合入，跑完一整套完整测试再上线。

把迁移范围控制在真正能提升可读性的地方

这个改动本身非常小，却刚好能把「可选字段的默认值」放回它本应该在的位置。项目完成全链路语言版本升级之后，优先替换那些完全只为取地址而存在的冗余临时变量；如果涉及复杂条件判断、需要复用值或是兼容旧版本的公共库场景，保留显式定义的变量或是辅助函数，代码可读性通常会更好。

相关问题

new(false) 会不会把 false 转成空值？

不会。它返回的是一个非空的 *bool，指向的实际值就是 false，和 nil 代表的空指针语义完全不一样。

go.mod 里写 go 1.26 之后，旧版编译器还能正常构建吗？

不要把这种场景当成可用的兼容方案。如果项目明确承诺支持旧工具链，就不要在普通业务代码里使用 Go 1.26 才新增的语法特性。

所有原来取地址的写法都值得改成 new(初始值) 吗？

没必要。只有当前临时变量完全只为了拿到一次性指针，用新语法能让字段的赋值意图和默认值靠得更近的时候，改动才能让代码更清晰。

new(初始值) 可以完全替代所有指针辅助函数吗？

在最低语言版本固定为 Go 1.26 的模块里，它可以砍掉很多简单的指针辅助函数；需要跨版本兼容的公共库，还是要按照预设的兼容目标来选择实现方式。