for循环在我们日常编码中可能用的很多。在很多业务场景中我们都需要用for循环处理。但golang中的for循环有一个大大大的坑，大家可否遇到。直接上代码：我们写一个测试类，定义一个切片数组，然后循环迭代每个元素，将元素的值放到另一个切片。循环finalArrays的时候按照我们的预期应该输出1、2、3、4。但事与愿违，输出的结果如下图：懵逼了吧！为什么会出现这种奇怪的现象呢？这就是golang的循环变量的作用域导致的。在golang的for循环中，循环内部创建的函数变量都是共享同一块内存地址，for循环总是使用同一块内存去接收循环中的的value变量的值。不管循环多少次，value的内存地址都是相同的。事实确实如此，我们输出value的内存地址看下：所以，可以看到，整个4次循环过程中，所有变量值都是在0xc0000b8780这个内存地址上进行迭代的。4次循环都指向的是同一块内存地址，最后一次赋值的操作变量的值是4，指向了这块内存地址，所以前三次的值都变成了4。那我们怎么优化呢？我们只需要定义临时变量。我们定义一个临时变量tmp，将value的值赋给tmp，问题就解决了。总结：①、fo
转： https://chenhe.me/post/inheritance-in-go/继承 vs 组合一句话解释，继承是「is sth」，组合是「has sth」。Go 采用组合完美契合了它鸭子类型（duck typing）的设计理念。“当看到一只鸟走起来像鸭子、游泳起来像鸭子、叫起来也像鸭子，那么这只鸟就可以被称为鸭子。鸭子类型中，我们重点关注对象能做什么，而不在意它究竟是什么。对这个理念我略有感触。曾经在 Kotlin (java) 开发中遇到过这样的问题：第三方包中有个类，没有抽象出接口，我恰恰需要扩展这个东西。于是只好自己定义一个接口，然后写个代理类或者用其他奇奇怪怪的方法达成目的。你看，它明明是我接口的实现，仅仅因为缺少 implements 关键字，我就得大费周章。在鸭子类型中这个问题不复存在。组合要比继承灵活得多。比如 java 中不能让「卡车」既继承「车」又继承「货运工具」，这又偏偏是显示情况。你不能建模为「车 <- 货运工具 <- 卡车」，因为货运工具也可能是飞机。而组合可以轻松办到：type Car struct { Id string } type
Xinbo
