CFSDN坚持开源创造价值，我们致力于搭建一个资源共享平台，让每一个IT人在这里找到属于你的精彩世界.

这篇CFSDN的博客文章golang简单的 For 循环也会踩的坑由作者收集整理，如果你对这篇文章有兴趣，记得点赞哟.

本文转载自微信公众号「crossoverJie」，作者crossoverJie。转载本文请联系crossoverJie公众号.

前言

最近实现某个业务时，需要读取数据然后再异步处理;在 Go 中实现起来自然就比较简单，伪代码如下:

1. list := []*Demo{{"a"}, {"b"}}
2. for _, v := range list {
3. go func() {
4. fmt.Println("name="+v.Name)
5. }()
6. }
8. type Demo struct {
9. Name string
10. }

看似非常简单几行代码却和我们的预期不符，打印之后输出的是:

1. name=b
2. name=b

并不是我们预期的:

1. name=a
2. name=b

坑一

由于写 go 的资历尚浅、道行更是浅薄，这 bug 我硬是找了个把小时;刚开始还以为是数据源的问题，经历了好几轮自我怀疑。总之过程先不表，先看看如何修复这个问题.

首先第一种办法是使用临时变量:

1. list := []*Demo{{"a"}, {"b"}}
2. for _, v := range list {
3. temp:=v
4. go func() {
5. fmt.Println("name="+temp.Name)
6. }()
7. }

这样便可正确输出，其实从这种写法中也能看出问题的端倪.

在第一种没有使用临时变量时，主协程很快就运行完毕，这时候打印的子协程可能还没运行;当开始运行的时候，这里的 v 已经被最后一个赋值了.

所以这里打印的一直都是最后一个变量.

而使用临时变量会将当前遍历的值拷贝一份，自然就不会互相影响了.

当然除了临时变量也可使用闭包解决.

1. list := []*Demo{{"a"}, {"b"}}
2. for _, v := range list {
3. go func(temp *Demo) {
4. fmt.Println("name="+temp.Name)
5. }(v)
6. }

将参数通过闭包传递时，每个 goroutine 都会在自己的栈中存放一份参数的拷贝，这样也能区分了.

坑二

与之类似的还有第二个坑:

1. list2 := []Demo{{"a"}, {"b"}}
2. var alist []*Demo
3. for _, test := range list2 {
4. alist = append(alist, &test)
5. }
6. fmt.Println(alist[0].Name, alist[1].Name)

这段代码与我们预期不不符:

1. b b

但我们稍加修改就可以了:

1. list2 := []Demo{{"a"}, {"b"}}
2. var alist []Demo
3. for _, test := range list2 {
4. fmt.Printf("addr=%p\n", &test)
5. alist = append(alist, test)
6. }
7. fmt.Println(alist[0].Name, alist[1].Name)
8. addr=0xc000010240
9. addr=0xc000010240
10. a b

顺便打印了内存地址，其实从结果中大概就能猜到原因;每次遍历打印的内存地址都是相同，所以如果我们存放的是指针，本质上存储的都是同一块内存地址的内容，所以值相同.

而如果我们只存储值，不存指针自然也不会有这个问题.

但如果想使用指针如何处理呢？

1. list2 := []Demo{{"a"}, {"b"}}
2. var alist []*Demo
3. for _, test := range list2 {
4. temp := test
5. //fmt.Printf("addr=%p\n", &test)
6. alist = append(alist, &temp)
7. }
8. fmt.Println(alist[0].Name, alist[1].Name)

也简单，同样的使用临时变量即可.

通过官方源码可以得知，for range 只是语法糖，本质上也是 for 循环;因为每次都是对同一个对象遍历赋值，所以便会出现这样的“乌龙”.

defer 的坑

for 循环 + defer 也是组合坑(虽然不推荐这么用)，还是先来看个例子:

1. // demo1
2. func main() {
3. a := []int{1, 2, 3}
4. for _, v := range a {
5. defer fmt.Println(v)
6. }
7. }
9. // demo2
10. func main() {
11. a := []int{1, 2, 3}
12. for _, v := range a {
13. defer func() {
14. fmt.Println(v)
15. }()
16. }
17. }

分别输出:

1. //demo1
2. 3
3. 2
4. 1
5. //demo2
6. 3
7. 3
8. 3

demo1的结果很好理解，defer 可以理解为将执行语句放入到栈中，所以呈现的结果是先进后出.

而demo2中，由于是闭包，闭包对变量 v 持有的是引用，所以在最终延迟执行时 v 已经被最后一个值赋值，所以打印出来都是相同的.

解决方法与上文类似，传入参数即可解决:

1. for _, v := range a {
2. defer func(v int) {
3. fmt.Println(v)
4. }(v)
5. }

这类细节问题日常开发大概率是碰不上的，最有可能遇到的就是面试了，所以多了解了解也没坏处.

总结

类似于第一种情况在 for 循环中 goroutine 调用，我觉得 IDE 完全是可以做到提醒的;比如 IDEA 中就把大部分认为可能发的错误包含进去，期待后续 goland 的更新.

但其实这几种错误官方博客已经提醒过了.

图片https://github.com/golang/go/wiki/CommonMistakes#using-reference-to-loop-iterator-variable只是大部分人估计都没去看过，这事之后我也得花时间好好阅读下.

原文链接：https://mp.weixin.qq.com/s/-UwjvRwi1mTDHEy3cw8mrA 。

最后此篇关于golang简单的 For 循环也会踩的坑的文章就讲到这里了,如果你想了解更多关于golang简单的 For 循环也会踩的坑的内容请搜索CFSDN的文章或继续浏览相关文章，希望大家以后支持我的博客！ 。