意外的切片追加行为

各位小伙伴们，大家好呀！看看今天我又给各位带来了什么文章？本文标题是《意外的切片追加行为》，很明显是关于Golang的文章哈哈哈，其中内容主要会涉及到golang等等，如果能帮到你，觉得很不错的话，欢迎各位多多点评和分享！

问题内容

我今天在 go 代码中遇到了奇怪的行为：当我追加elements到slicein 循环然后尝试slices根据循环的结果创建新的时，lastappend覆盖slices从 previous appends。

在这个特定的例子中，这意味着sliceFromLoop j,g和hslice 的最后一个元素分别不是100,101和102, 但是...总是102!

第二个示例 -sliceFromLiteral行为符合预期。

package main

import "fmt"

func create(iterations int) []int {
    a := make([]int, 0)
    for i := 0; i 
链接到 play.golang： https:
//play.golang.org/p/INADVS3Ats
经过一些阅读、挖掘和实验，我发现这个问题源于slices引用相同的底层array
值，可以通过slice在附加任何内容之前复制到新的值来解决，但是它看起来很......犹豫不决。
基于旧切片创建许多新切片而不担心更改旧切片的值的惯用方式是什么？

    正确答案

不要分配append给它本身以外的任何东西。
正如您在问题中提到的那样，混淆是由于append两者都更改了基础数组并返回了一个新切片（因为长度可能会更改）。您可以想象它复制了该支持数组，但它没有，它只是分配一个slice指向它的新对象。由于i从不改变，所有这些附加都会不断将值更改backingArray[12]为不同的数字。
将此与 ing 与数组进行对比append，数组每次都分配一个新的文字数组。
所以是的，您需要先复制切片，然后才能对其进行处理。
func makeFromSlice(sl []int) []int {
    result := make([]int, len(sl))
    copy(result, sl)
    return result
}

func main() {
    i := make([]int, 0)
    for ii:=0; ii
解释切片文字行为是因为如果追加超出后备数组的， ** 则会分配一个新数组。**cap这与切片文字无关，而与超出上限的内部机制有关。
a := []int{1,2,3,4,5,6,7}
fmt.Printf("len(a) %d, cap(a) %d\n", a, len(a), cap(a))
// len(a) 7, cap(a) 7

b := make([]int, 0)
for i:=1; i
到这里，我们也就讲完了《意外的切片追加行为》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于golang的知识点！