2025 年 12 月 16 日，Go 团队从 Go 1.26 发布分支切出了 Go 1.26 Release Candidate 1 (go1.26rc1)，并向社区发出了明确的测试请求：请使用你们的单元测试和生产负载测试来检验它。
发布说明草案提到，Go 1.26 预计在 2026 年 2 月正式发布。
RC1 的发布意味着这个版本已经足够稳定和完整，值得开发者认真对待。其主要特性已经就位，轮廓定型，后续工作通常只剩下修复 Bug、微调性能以及解决实际测试中暴露的问题。这也正是 RC1 阶段最重要的价值所在。
现在，是回答这两个关键问题的最佳时机：
- Go 1.26 有哪些变化，真的会影响生产系统？
- 你现在应该测试什么，才能避免升级后才遭遇意外？
下面我们将直接剖析 RC1 所揭示的关键信息，并指出哪些地方值得你重点关注。
RC1 真正意味着什么
Go 团队在 RC 公告中的措辞非常直白：“跑你们的生产负载测试，跑你们的单元测试，有问题就报。”
换句话说：Go 1.26 的形态已接近最终版，但只有来自真实场景的工作负载，才能帮助我们共同发现潜在问题。
因此，RC1 对不同角色的团队而言，是一个明确的行动信号：
- 如果你维护库：现在就是测试兼容性的最佳时机，发现问题还有修复的窗口期。
- 如果你运行线上服务：现在进行一次 Canary 或 Staging 环境的长时浸泡测试，远比在正式版发布后被迫回滚要从容得多。
- 如果你分发 CLI / Agent / 工具链：现在就应该在你所支持的所有操作系统和架构组合上完整测试一轮，Go 1.26 的平台支持变化不容忽视。
值得真正关心的变化
1. 一个微小但实用的语言改动：new(expr)
Go 1.26 扩展了内置的 new 函数：它现在不仅可以接收一个类型作为参数，也可以接收一个表达式。
这意味着 new(expr) 的写法变得合法，它会返回一个指向“用该表达式初始化后的值”的指针。
这个改动看似很小，但在涉及大量 DTO、序列化或可选字段的场景中，能显著提升代码的简洁性。
示例 (Go 1.26):
type Person struct {
Name string `json:"name"`
Age *int `json:"age,omitempty"` // nil 表示未知
}
func yearsSince(t time.Time) int {
return int(time.Since(t).Hours() / (365.25 * 24))
}
func personJSON(name string, born time.Time) ([]byte, error) {
return json.Marshal(Person{
Name: name,
Age: new(yearsSince(born)), // Go 1.26：new(expr)
})
}
在以前，你不得不先定义一个临时变量，再取其地址。现在，这段代码终于可以一气呵成。
需要测试什么：任何假设 new 关键字后只能跟类型的工具都可能受影响，例如代码生成器、AST 分析工具以及 Linter/Formatter。
2. 会悄悄影响日常工作的工具链变化
go mod init 默认写入更低的 Go 版本
从 Go 1.26 开始，go mod init 将不再默认写入当前的 Go 版本号。
- 在 RC 阶段，它写入
go 1.24.0。
- 在正式的 Go 1.26 版本中，它将写入
go 1.25.0。
此举的目的是鼓励模块保持对“当前受支持的 Go 版本”的兼容性。
但现实中的副作用是：
- 在 CI 中校验
go.mod 文件的脚本可能会因为版本号差异而报错。
- 团队成员可能会困惑：“我明明在用 Go 1.26，为什么
go.mod 里不是？”
如果需要显式设置为更高版本，可以再次运行：
go get go@1.26
go tool doc 被移除
在 Go 1.26 中，cmd/doc 和 go tool doc 命令均已被删除。请统一使用：
go doc
其参数和行为与之前保持一致。
需要测试什么：CI 脚本、开发容器配置、内部文档以及任何遗留的自动化脚本。
go fix 彻底更换“内核”
go fix 命令现在基于 Go analysis 框架（与许多 go vet 分析器同源），并移除了历史遗留的旧修复器，换用了一套新的。
如果你在自动迁移、批量重构或升级脚本中使用过 go fix，现在就应该运行一次，仔细检查它具体修改了哪些内容。
pprof Web UI 默认变为火焰图
当你使用以下命令时：
go tool pprof -http=...
现在默认打开的视图是火焰图 (flame graph)。传统的图视图仍然存在，只是不再是默认首页。
这更多是用户体验上的变化，但对于性能排查的工作流程会产生一定影响。
3. 真正影响生产指标的运行时变化
Green Tea GC 默认开启
之前在 Go 1.25 中作为实验特性引入的 Green Tea GC，现在于 Go 1.26 中默认启用。
它的目标是：
- 降低 GC 开销。
- 改善某些工作负载下的 CPU 使用率。
- 改变 GC 的节奏（不同负载差异可能较大）。
你可能会观察到：
- 分配密集型服务的 CPU 使用率下降。
- GC 暂停时间的形态发生变化。
- 某些场景下的尾延迟（p95/p99）发生变化。
必须认真测试的点：高分配频率的热点路径、突发流量场景，并且务必关注 p95 / p99 延迟，不要只看平均值。
如果发现性能回退，Go 团队明确表示可以临时通过环境变量退出，并希望你提交 Issue 报告。
cgo 调用开销下降约 30%
Go 1.26 降低了 cgo 调用的基础开销。
如果你的服务使用了 cgo 数据库驱动、调用了图像/视频处理库，或者使用了特定的 C/C++ 压缩/加密实现，那么这个变化可能会直接改变性能瓶颈的位置，值得运行基准测试进行验证。
小对象分配走 size-specialized 路径
编译器现在会为小于 512 字节的小对象生成 size-specialized 分配调用。
这个改动的影响看似微小，但在高频对象分配或热路径循环中，可能带来实实在在的性能收益。
目前仍然可以通过设置环境变量来关闭此优化：
GOEXPERIMENT=nosizespecializedmalloc
但这只是一个过渡选项。
4. 可观测性：Goroutine 泄漏分析（实验性）
Go 1.26 引入了一个实验性的 Goroutine 泄漏分析功能：
- 通过
GOEXPERIMENT=goroutineleakprofile 启用。
- 提供
/debug/pprof/goroutineleak 端点。
如果你曾经历过“Goroutine 数量缓慢增长，却无人知晓泄漏源头”的困境，就会明白这个工具为何令人期待。
建议：
- 在 Staging 环境中开启测试。
- 使用已知的泄漏案例或构造测试用例进行验证。
- 将其视为强大的“诊断工具”，而非一劳永逸的解决方案。
5. 标准库：安全与性能的长期布局
几个值得注意（但不一定立即使用）的更新：
crypto/hpke：支持 RFC 9180，包含后量子混合 KEM。simd/archsimd（实验性）：提供架构相关的 SIMD 指令支持（目前针对 AMD64）。runtime/secret（实验性）：用于敏感数据的安全擦除。
这些变化释放出一个明确信号：Go 团队正在持续补强安全原语、铺设性能基础设施，但依然保持着默认的克制态度。
6. 平台 / 端口变化（不容忽视）
这些变化最容易在版本发布时“悄无声息地造成问题”：
- Go 1.26 是最后一个支持 macOS 12 (Monterey) 的版本。
- 32-bit windows/arm 支持已被移除。
- Go 1.26 是最后一个支持 Linux big-endian ppc64 的版本。
linux/riscv64 现在支持竞态检测器 (race detector)。
如果你需要分发二进制文件，务必：
- 核对并更新支持矩阵。
- 在 CI 流水线中进行验证。
- 在 README 等文档中清晰说明。
如何安全地试用 go1.26rc1
官方推荐使用版本化的包装器来安装和测试，以避免污染主环境：
go install golang.org/dl/go1.26rc1@latest
go1.26rc1 download
go1.26rc1 version
随后，你可以使用它来运行测试：
go1.26rc1 test ./...
go1.26rc1 test -race ./...
此外，还应使用它来构建产物、在 Staging 环境部署，并运行一次接近真实数据量的负载测试，这对于评估像 Green Tea GC 这样的后端 & 架构层面的运行时变更至关重要。
RC1 阶段你应该做什么
如果你在生产环境中运行 Go 服务，面对 RC1，首要行动不是“立即升级”，而是立即开始收集证据。
一份可靠的 RC 测试清单应包括：
- 使用 go1.26rc1 运行完整的 CI 流水线。
- 对并发密集的模块运行竞态检测 (
-race)。
- 为关键路径（如请求处理器、消息消费者、序列化/反序列化、缓存逻辑）运行基准测试。
- 密切观察 p95 / p99 延迟等指标。
- 验证工具链变更（
go mod init, go doc, go fix）对你工作流的影响。
- 验证所有目标平台的构建是否正常。
这些运维/DevOps/SRE环节的验证，目的就是让潜在的“惊喜”在正式版发布前、仍有修复机会的时候暴露出来。
总结
从 RC1 和发布说明草案来看，Go 1.26 正在演变为这样一个版本：
- 包含一个虽小但实用的语言改进 (
new(expr))。
- 工具链在推动更稳健的模块兼容性与现代化。
- 运行时变化足以影响真实的生产环境指标。
- 持续在安全与性能库方面打下基础，但不过度激进。
- 平台支持策略更加明确和果断。
而最重要的一点是：Go 团队明确希望你现在就用真实的工作负载来测试它，而不是等到 2026 年 2 月正式版发布。
这就是 RC1 的核心价值。希望这份解读能帮助你在云栈社区及自己的项目中，更高效、更安全地迎接 Go 1.26。
发表于 20 小时前
|
查看: 2|
回复: 0
