Go modernize 的 newexpr 为什么不改数值类型：显式类型与转换边界

把 ptrTo[uint32](42) 交给 Go 的 modernize/newexpr 后，很多人会疑惑：布尔值和部分浮点值已经改成 new(expr)，为什么显式写出的 uint32、int64 仍原样保留？核心原因不是分析器“没看见”，而是直接删掉类型参数可能把指针类型从 *uint32 改成 *int，这已经越过了安全重写的边界。

为什么 uint32 和 int64 没有被直接改写

Go 1.26 允许 new 接收值表达式。官方 modernize 文档说明，newexpr 会识别返回参数地址的辅助函数，并尝试把调用替换成 new(expr)。但这个替换必须保持程序行为，不能只追求代码更短。

func ptrTo[T any](v T) *T { return &v }

var a = ptrTo[uint32](42) // *uint32
var b = ptrTo[int64](23)  // *int64
var c = ptrTo(true)       // *bool

在 ptrTo[uint32](42) 中，显式类型参数 uint32 决定了 参数 v uint32。如果机械替换为 new(42)，无类型整数会落到 默认类型 int，结果变成 *int。真正保持语义的写法是 new(uint32(42))，其结果仍为 *uint32。

默认类型决定哪些调用可以安全缩短

Go 规范规定，无类型常量在需要确定类型时会使用默认类型：整数是 int，浮点数是 float64，布尔值是 bool。因此 ptrTo(true) 与 new(true) 都围绕 bool，通常可以直接改写；ptrTo[float64](3.14) 也恰好和浮点常量的默认类型一致。

显式指定非默认数值类型时就不同。ptrTo[int64](23) 若要保持 *int64，需要写成 new(int64(23))。这不是排版差异，而是泛型实参与常量默认类型之间的转换责任。分析器在没有完成可靠转换前保守地不改，比生成一个能编译但类型不同的补丁更安全。

批量运行 go fix 后怎样把住生产边界

官方文档强调，modernize 的目标是批量应用时不改变程序行为，但生成的修改仍应进入正常的 代码审查。执行 go fix -newexpr ./... 后，先搜索遗留的 ptrTo[ 调用：它们可能正是显式数值类型、局部遮蔽 new 或公开辅助函数等保守边界。

把 go fix -newexpr 放进独立提交更容易审查；随后让编译、测试和静态检查覆盖所有包。当前问题单只是 FeatureRequest，并且仍处于 Unreleased 里程碑，不能把尚未合入的行为当成已经发布的工具承诺。

相关问题

为什么 new(42) 不是 *uint32？

因为 42 是无类型整数常量，没有其他类型上下文时使用默认类型 int，所以 new(42) 返回 *int。

可以手工把它改成 new(uint32(42)) 吗？

可以，但要确认原辅助函数没有额外校验、别名语义或 API 兼容责任；批量修改前后都应由编译和测试验证。

判断标准

看到 newexpr 留下显式数值泛型调用时，先比较“辅助函数参数类型”和“表达式默认类型”。两者一致，才有直接缩短的基础；两者不同，就需要显式转换。保守未改写并不等于工具失效，它是在等待一个能证明类型保持不变的修复方案。

参考：Go issue #81196、modernize 官方文档、Go 1.26 Release Notes、Go 语言规范。