Go 1.22 未新增 for range 语法，核心更新包括：循环变量不再复用、slices/map 标准库增强、go work vendor 支持、vet 新警告及 trace UI 升级。
Go 1.22 没有新增 for range 语法，所谓“增强循环”是误传；真正值得用的新特性集中在标准库（slices、maps）、工具链（go work vendor、vet 警告）和运行时优化上。
for range 循环变量不再复用：闭包和 goroutine 行为变了
Go 1.22 正式将 loopvar 特性转正：每次迭代的 i 和 v 是独立变量，不是复用同一内存地址。这直接修复了长期存在的闭包捕获陷阱，但别当成“bug 修好了”来用——它只是让错误代码不那么稳定地失败。
- 旧写法（Go 1.21 及之前会出错，Go 1.22 虽然“碰巧”对了，但逻辑仍脆弱）：
for i, v := range items { go func() { fmt.Println(i, v) }() } - 正确写法（显式传参，兼容所有版本）：
for i, v := range items { go func(idx int, val string) { fmt.Println(idx, val) }(i, v) } - 若需在循环中取地址（比如存指针到切片），必须用索引：
ptrs := make([]*string, len(items)) for i := range items { ptrs[i] = &items[i] // 不能写 &v }
slices.Concat、slices.Delete 等函数正式落地：切片操作不用再手写了
Go 1.22 把 slices 包里一批泛型函数从实验阶段移入稳定标准库，覆盖拼接、删除、插入、去重等高频场景。它们不是语法糖，而是经过类型安全和边界检查验证的可靠实现。
-
slices.Concat支持多个同类型切片拼接：res := slices.Concat(s1, s2, s3)
注意：参数必须是相同元素类型的切片，不能混用[]int和[]string -
slices.Delete删除指定索引区间后，**自动将被删位置之后的元素归零**（Go 1.22 行为变更）：s = slices.Delete(s, 2, 4) // 删除索引 2~3，s[2] 和 s[3] 变成零值
这点和旧版append(s[:i], s[j:]...)不同，后者不清理内存 -
slices.Compact和slices.CompactFunc用于去重，前者按相等比较，后者接受自定义判断逻辑
go work vendor 和 GOPROXY 必须配：模块管理已不可绕过
Go 1.22 彻底放弃对 GOPATH 模式下 go get 的支持，同时补全了工作区（go work）对 vendor 目录的支持。这意味着本地依赖隔离和离线构建能力终于完整了，但前提是配置到位。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 启用 vendor：
go work vendor
生成vendor/目录，之后go build -mod=vendor即可离线编译 - 国内用户不设
GOPROXY，go mod download几乎必卡死：go env -w GOPROXY=https://goproxy.cn,direct
direct必须保留，否则私有 Git 仓库无法拉取 - 新建项目别再进
$GOPATH/src，直接任意路径执行：go mod init myapp
并确保GO111MODULE=on（建议全局设置：go env -w GO111MODULE=on）
vet 工具新增警告和 trace Web UI 升级：调试体验变实了
Go 1.22 的 go vet 开始检测循环变量捕获、append 后未使用返回值、time.Since 在 defer 中误用等问题；go tool trace 的 Web UI 重写后，线程视图、系统调用持续时间展示更直观——但这些改进只对 Go 1.22+ 编译的程序生效。
- 运行静态检查：
go vet ./...
特别留意loop variable captured by func literal类警告，它指向的就是前面说的i/v闭包问题 - 生成 trace：
go run -trace=trace.out main.go
然后打开go tool trace trace.out，新版 UI 支持按 P（processor）或 OS thread 过滤，比以前更容易定位调度延迟 - PGO（Profile-guided Optimization）构建现在更有效，但需要先采集 profile：
go build -gcflags=-pgobootstrap=profile.pb.gz
再用go tool pprof分析，普通项目暂不建议强上
最易被忽略的是：Go 1.22 对内存分配器大小类边界的调整，可能让某些依赖特定内存布局的 cgo 或 unsafe 代码出现行为偏移；还有 macOS 用户要注意，这是最后一个支持 Catalina（10.15）的 Go 版本——升级系统和 Go 必须同步考虑。
