Go 1.21 实现后，真正影响日常编码的改动集中在三块：泛型类型推导放宽、slices/maps 标准库包转正、以及工具链对循环变量语义的调整。原文把重点放在“多架构一条命令构建”和“slices.ForEach 配合实验开关”上，这两点与官方发布内容对不上，照抄会踩坑。下面按实际可用的能力重新梳理。
泛型推导：放宽的是上下文，不是万能
1.21 对类型推导的改进，核心是允许从赋值目标和函数实参两个方向同时收集类型信息，多级嵌套场景下少写显式实例化。原文那段 Transform 示例方向是对的，但要注意：推导失败时编译器报错依旧直接，不会替你猜。
func Transform[T any](s []T, fn func(T) T) []T {
r := make([]T, len(s))
for i, v := range s {
r[i] = fn(v)
}
return r
}
// 实参已携带 T=int，可省略
out := Transform([]int{1, 2, 3}, func(x int) int { return x * 2 })
真正容易卡住的是方法值和混合参数。比如把 fn 写成 strconv.Itoa 这类签名不完全匹配的函数值，或者类型参数只出现在返回值里，推导就会失败，此时仍需 Transform[int](...) 兜底。写泛型库时建议保留显式实例化的调用路径，别把推导当契约。
slices 包：能用，但别信原文的 API
slices 和 maps 在 1.21 从 x/exp 转正，提供的是 Sort、SortFunc、Contains、Index、Clone、Compact 这类基础操作。原文提到的 slices.ForEach 并不存在，GOEXPERIMENT=preemptibleloops 也不是启用它的开关——这个实验项与切片遍历无关。按原文写会直接编译报错。
实际可用的排序写法：
slices.SortFunc(users, func(a, b User) int {
return cmp.Compare(a.Age, b.Age)
})
比较函数返回 int，配合标准库 cmp.Compare 最省事。slices.Clone 是浅拷贝，元素含指针或 map 时内部引用仍共享，别拿它当深拷贝用。至于性能，排序和查找确实比手写循环更稳，但不存在原文所称“百万级元素耗时降到 72%”这种统一数字，收益取决于数据分布和比较函数开销，上线前用 go test -bench 在自己的数据集上量一遍。
跨平台构建：没有 -arch 多值参数
1.21 没有引入 go build -arch amd64,arm64 这种一次产出多架构的语法。跨平台构建仍是老办法：设 GOOS/GOARCH 逐个编译，或用 goreleaser、docker buildx 编排。
for arch in amd64 arm64; do
GOOS=linux GOARCH=$arch go build -o bin/app-$arch ./cmd/app
done
单次编译的缓存复用是工具链既有能力，跨架构之间并不共享产物，原文“编译时间缩短 40%”没有依据。CI 里想省时间，正确做法是并行跑多个 job，每个 job 固定一组 GOOS/GOARCH，缓存 GOPATH 和 build cache。
循环变量与升级评估
1.21 把循环变量改为每次迭代新建，这会影响闭包捕获 i 的老代码——以前靠 i := i 兜底的写法可以删，但依赖共享变量的逻辑要重新审。升级前建议做三件事：跑全量测试、用 go vet 扫一遍、对热点路径补基准测试。逃逸分析和内联策略在版本间会有微调，微观性能特征可能变化，基准套件比口头承诺可靠。
泛型推导和 slices 包组合起来，确实能压掉一批样板代码，但前提是按真实 API 写。原文里虚构的命令和开关，恰恰是升级路上最该避开的部分。
ID:6703
