Go 1.22
Go 1.22 引入了若干值得注意的语言和标准库变化，包括可对整数进行 range 的 `for` 循环、实验性的对函数进行 range 的迭代器、`net/http` 中改进的 HTTP 路由，以及 `sql.Null[T]` 之类的新辅助工具，同时也收紧了切片和 I/O 的行为。工程师们总体欢迎这次发布，因为它保留了 Go 一贯的简洁高效工具链——自动工具链升级、快速构建、强大的标准库——尤其是与配置沉重的 TypeScript/JavaScript 生态相比。与此同时，也有人担心像迭代器和新的 range 形式这样的特性会逐渐削弱 Go 的极简主义及其强后向兼容保证，而这些现在又部分通过 `go.mod` 版本门控和环境变量标志来管理。
交互式发布说明
- 社区制作的 1.22 说明交互版（带可运行/可编辑示例）广受好评，因为它让这些变化——尤其是像
for循环变量语义这样细微的变化——更容易理解。 - 关于
Compact/Replace之类切片函数的一些困惑也得到澄清：现在收缩类函数会将旧长度和新长度之间的元素清零。
采用新的 Go 版本与操作系统限制
- 许多生产用户会很快升级，有时会在发布后立即升级，或在第一个小版本发布后升级，并依赖测试和便捷回滚（容器镜像、CI）。
- 一些组织在所有仓库中统一使用同一个 Go 版本；另一些则允许单个服务更快迁移。
- 一个显著阻碍是对旧操作系统的支持（例如 Windows 7、Server 2012、较旧的 macOS），这迫使一些团队尽管担心安全问题，仍然在 1.20 上停留多年。
go.mod通过新工具链自动下载被认为让升级变得非常容易，不过当库在没有带来收益的情况下提高所需版本时，下游用户会受到影响。
新的语言特性（range、迭代器、sql.Null）
- 对整数使用
for range受到欢迎，因为它像for x in range(10)这样熟悉；但也有人觉得它含糊且不必要，不如经典的for i := 0; i < 10; i++。 - 也有人提到边界行为（例如负整数会导致零次迭代）。
- “对函数进行 range”的迭代器让那些想要真正迭代器和惰性序列的人感到兴奋；但也有人不喜欢新增的复杂性和函数式风格，觉得与 C#/Python 中的
yield相比它过于冗长。 sql.Null[T]很受欢迎；大家讨论了用于区分“未设置”与“有意为 null”的模式，尤其是在部分更新中。
HTTP 路由与标准库演进
net/http中增强的路由模式受到欢迎；不少人希望借此移除 chi/Gorilla mux 这类第三方路由器。- 也有人担心路径语义的变化（例如
{}的处理）以及其他行为调整会给 Go 1 的兼容性承诺带来压力，尽管这些变化受go版本和GODEBUG标志控制。
Go 与 TypeScript/Dart，以及语言哲学
- 多位评论者将 Go 的极简、强意见式设计和统一工具链，与 JS/TS 生态中沉重的配置、库选择以及日益复杂的类型系统进行了对比。
- 有些人怀念 map/filter 风格的切片辅助函数，并喜欢
lo之类的库；但也有人认为这会形成第二套“DSL”，更偏好显式循环，因为这样更清晰。 - Dart 和现代 Java 被引用为例子，说明功能不断叠加、同一件事有多种做法，会让代码更难理解和重构；Go 则因减少“花哨技巧”并促进共享理解而受到赞赏，不过也有人觉得相比 Python，Go 的冗长有点像“法律文书”。
工具、embed 与性能改进
go:generate和go:embed被强调为重大生产力提升：可从 protobuf/XSLT 生成代码，并将 Web 资源、eBPF 或 SQL migration 打包进单一二进制文件。- 标准库持续进行的微优化（例如
io.Copy在某些 socket 对之间使用 Linuxsplice）被视为“白捡”的性能提升。 - 有人担心标准库里的特殊处理很难在其外部复制，但也接受这属于预期之内。
兼容性担忧与未决问题
- 改变
for-range 变量语义被视为一种务实的修复常见 bug 的做法，但从技术上讲仍属于破坏性变更；有人认为 Go 应该通过重大版本号升级，而不是通过不断累积环境变量标志来处理这些问题。 - 还有人提问 1.22 是否修复了某个特定的 Go 1.21 Linux 内存问题；该讨论没有给出明确答案（不清楚）。