如何避免 Go 语言中递归遍历切片时指针被意外覆盖的问题-Golang-PHP中文网

在 go 中对结构体切片递归遍历并追加元素时，若直接对 range 循环变量取地址传入递归函数，会导致所有指针指向同一内存地址，造成数据污染和结果异常。

在 go 中对结构体切片递归遍历并追加元素时，若直接对 range 循环变量取地址传入递归函数，会导致所有指针指向同一内存地址，造成数据污染和结果异常。

在 Go 的 for _, tag := range slice 循环中，tag 是一个复用的循环变量——它在每次迭代中被重新赋值，但其内存地址始终不变。当你执行 &tag 时，得到的始终是该变量的同一地址。因此，即使你在不同递归层级中将 &tag 追加到 *[]*HtmlTag 中，所有指针最终都指向同一个栈上被反复覆盖的 tag 实例。一旦下一次迭代发生，tag 的内容被更新，之前追加进切片的所有指针所指向的数据也会随之“悄然改变”，导致观察到的 matchingDivs 内容在递归过程中不一致甚至错乱。

这是一个典型的 Go 闭包与循环变量陷阱（与 FAQ 中 Closures and Goroutines 场景本质相同），核心在于：range 变量的生命周期跨越整个循环，而非每次迭代独立分配。

✅ 正确做法是为每次迭代创建独立的变量副本，确保每个 &tag 指向唯一、稳定的内存地址。以下是两种推荐方案：

方案一：显式重声明变量（推荐，语义清晰）

使用Go语言搭建家庭相册系统-相关课件

下载

for _, tag := range htmlTag.ChildTags {
    tag := tag // 创建新的局部变量，获得独立地址
    getAllCertainDivs(className, idName, &tag, matchingDivs)
}

方案二：通过索引访问（避免变量复用，性能略优）

for i := range htmlTag.ChildTags {
    getAllCertainDivs(className, idName, &htmlTag.ChildTags[i], matchingDivs)
}

⚠️ 注意事项：

不要依赖 &htmlTag.ChildTags[i] 在切片扩容时的稳定性（但 ChildTags 通常为固定结构字段，非动态扩容切片，风险较低）；
若 HtmlTag 结构体较大，方案一存在一次值拷贝开销，但对正确性而言完全值得；
始终用 fmt.Printf("%p", &tag) 打印地址验证是否真正独立，是调试此类问题的有效手段。

总结：Go 的 range 语义决定了循环变量复用是设计使然，而非 bug。理解这一机制，并主动创建作用域隔离的变量副本，是编写健壮递归或并发代码的关键习惯。