Go 1.26 正式发布，带来了 new(expr) 语法糖和 Green Tea GC 等备受期待的新特性。然而，当你兴冲冲地更新到最新版本，想要立刻体验新语法时，却可能遭遇一记“闷棍”。
创建一个新项目试试看：
$ mkdir test && cd test
$ go mod init mytest
$ cat <<EOF > main.go
package main
import "fmt"
func main() {
fmt.Println(new(42))
}
EOF
$ go build
你本期待编译成功，得到的却是报错：
./main.go:5:14: new(42) requires go1.26 or later (-lang was set to go1.25; check go.mod)
注：使用 go run 不会遇到此问题。go run 主要用于快速运行 Go 程序，它会直接使用当前 Go 工具链版本（例如 Go 1.26.0）执行代码，而不会验证 go.mod 中的版本声明。
“什么情况？我用的明明是最新的 Go 1.26 工具链！”
困惑中，你打开刚刚生成的 go.mod 文件，里面赫然写着：
module mytest
go 1.25.0
没错。从 Go 1.26 开始，go mod init 默认生成的不再是当前工具链版本（1.N），而是后退了一个大版本（1.N-1）。如果你使用的是 RC 预览版，它甚至会后退两个版本（1.N-2）。这意味着，要使用新版本的语言特性，你必须手动修改 go.mod 文件，或者额外执行 go get go@1.26.0。
这个打破 Go 开发者十年肌肉记忆的改动，迅速在 GitHub 上引爆了争议。在 Issue #77653 中，社区与 Go 核心团队展开了一场火药味十足的“大辩论”。
官方视角的“良苦用心”：为了生态的平滑演进
要理解这个“反直觉”的改动，需要先代入 Go 核心团队（特别是那些维护庞大开源生态和基础设施的工程师）的视角。
该改动源于 Go 1.26 开发周期中的 Issue #74748。官方团队成员 dmitshur 提出了修改建议，并得到了 mvdan 等资深贡献者的支持。他们的核心论点是：盲目要求最新版本，是一种对下游极其不友好的行为。
遵循“支持两个最新大版本”的官方承诺
Go 官方的维护策略是始终支持最近的两个主要版本（在 1.26 发布时，即 1.26 和 1.25）。dmitshur 认为，如果开发者在 1.26 发布的第二天就用 go mod init 创建并发布了一个开源库，默认的 go 1.26 声明将导致所有仍在使用受支持的 1.25 版本的下游用户无法直接编译此库。
“新的默认值永远不会切断任何一个当前受官方支持的 Go 工具链。” —— dmitshur
倒逼开发者做出“有意识的选择”
go.mod 中的 go 1.x 指令不仅控制着语言特性（Language Version），还控制着 GODEBUG 的默认行为。官方团队认为，放弃对旧版本的兼容性，应该是一个“有意识的（Conscious）”决定。
mvdan 在辩论中直言：“我们不应该鼓励新的 Go 用户在新语言特性一出现时就立即使用它们。因为使用了新特性而破坏对旧版本用户的兼容性，这应该是一个深思熟虑的选择。”
简而言之，Go 官方希望把 go mod init 变成一种“刹车机制”：默认让你兼容更广泛的版本，除非你确实需要最新特性，届时再去手动升级。
社区的全面反弹：被牺牲的“开发者体验”
官方的解释并未说服社区。Issue 的发起者 willfaught 与众多开发者提出了连串反驳，直指这一决策的逻辑漏洞。
违背“最小惊讶原则”
软件设计的铁律之一是“所见即所得”。用户下载了 Go 1.26，理所当然地认为开箱即用的是 1.26 的全部能力。如今官方宣传着 new(expr) 等新语法，但新手按教程敲下 go mod init 后，新语法却全部报错。这种认知断层对新手极不友好，徒增挫败感。
“所有代码都是公共库”的虚假前提
官方论点的基石是“保护下游调用者”。但社区尖锐地指出：世界上 99% 的 go mod init 都是为了创建私有项目、业务微服务或个人实验代码。
“公共模块的维护者确实需要考虑兼容性，但为什么要让数以百万计的普通应用开发者，去为那几十个核心开源库作者的便利买单？”
对于编写业务代码或自用工具的开发者而言，唯一的诉求就是用最新的工具写最高效的代码。强迫这 99% 的人每次都要手动执行 go mod edit -go=1.26，是典型的“为了 1% 的特例惩罚 99% 的大众”。
社区还指出，官方的担忧在 Go 1.21 引入了向前兼容的工具链下载机制（GOTOOLCHAIN=auto）后，已基本不复存在。
如果一个库要求 go 1.26，而下游用户使用 Go 1.25，Go 1.25 的工具链会自动、透明地在后台下载 1.26 的编译器来完成构建。既然工具链已能智能解决版本不匹配，为何还要在初始化时进行人为降级限制？这引发了许多关于开发流程效率的思考，你可以在技术文档板块找到更多关于现代化开发工具设计的讨论。
虚假的安全感
开发者 rittneje 指出了一个关键逻辑漏洞：go 1.25 只能阻挡语法层面的新特性。如果开发者在声明为 go 1.25 的模块中，使用了 Go 1.26 标准库新增的函数，这不会触发编译器版本阻拦，但下游的 1.25 用户拉取代码后依然会编译失败。
这意味着，官方强推的 N-1 降级策略，连其宣称的“严密保护兼容性”都难以完全实现。
程序的傲慢与僵化的治理
在这场辩论中，比技术分歧更令人不安的，或许是 Go 核心团队在回应社区反馈时的态度。
当社区列出详尽、严密的反对意见后，Go 核心成员 Ian Lance Taylor 的回复却显得十分冷淡：
“大家都知道，我们决策的准则之一是：一旦我们做出了决定，除非有新的信息，否则我们不会重新审视它。否则我们将陷入无休止地重新考虑旧决定的循环中。恕我直言，我没有看到任何会导致我们重新审视此决定的新信息。”
这段回复引发了强烈不满。开发者们指出，最初导致这个改变的提案（#74748）甚至没有经过标准的 Go 提案审查流程（Proposal Process）。它作为一个普通的功能请求被内部人员提出，在小范围讨论后便被直接合并。
“新信息就是：大多数开发者在 1.26 发布后才感知到这个隐蔽的改动，并认为这是一个糟糕的默认体验。” 开发者们如此反驳。当官方以“没有新信息”为由拒绝倾听关于“开发者体验”的反馈时，Go 团队长期被诟病的某种“家长式”作风似乎再次显现。这种开发者与维护者之间的观点碰撞，在开发者广场是经常被讨论的话题。
哲学的分歧：工具为谁设计？
纵观整场风波，它远不止是 go mod init 输出什么字符串的技术细节，更是一场关于“工具链默认行为到底应该优先服务于谁”的哲学碰撞。
- Go 核心团队（维护者视角）：他们站在整个生态系统的顶端，每日处理版本碎片化、库冲突等宏观问题。对他们而言，保守、稳定、不破坏现有兼容性是最高优先级。因此，他们倾向于将“默认设置”作为一种引导或教育手段。
- 广大 Gopher（一线开发者视角）：他们身处业务交付一线，面临迭代压力。对他们而言，直觉、效率、无缝的体验才是最高优先级。更新了编译器，就希望能立刻获得其全部能力，而非被工具链“教导”兼容性大道理。
在 Rust 社区，Cargo 鼓励使用最新的 Edition；在 Node.js/Python 社区，追逐新版本也是常态。而 Go 似乎正选择一条更强调稳定和约束的道路。
小结：如何应对 Go 1.26 的新常态？
就目前情况看，Go 团队短期内撤回此决定的可能性不大。作为 Gopher，我们需要适应这个略显尴尬的“新常态”。
如果你希望在新项目中无缝使用最新的 Go 特性，可以尝试以下两种策略：
- 修改习惯：创建新项目时，养成执行组合命令的习惯：
go mod init mymodule && go get go@latest
- 设置 Shell 别名：在
.zshrc 或 .bashrc 中添加别名，一键完成初始化和版本升级：
alias gomodinit='f() { go mod init "$1" && go mod edit -go=$(go env GOVERSION | sed "s/go//") ; }; f'
Go 1.26 无疑是一个强大且充满亮点的版本，但 go mod init 的这一小段“降级”插曲，确实在开发者体验上制造了波澜。技术工具的演进，永远在“严谨的安全网”与“极致的流畅度”之间寻找平衡。这一次，Go 的选择显然更倾向于前者。对于 Go 语言生态中的此类后端 & 架构治理决策，你的看法如何？是支持官方的克制，还是认同社区的批评？
发表于 20 小时前
|
查看: 1|
回复: 0
