一个常见的场景：你定义了一个函数，接收参数类型写成[3]int，调用时传入一个长度为3的数组，函数内部修改了某个元素，回到调用方打印原数组却还是旧值。这不是Go的bug，而是数组的值类型特性在起作用。要理解这个问题，得先明白Go语言里数组和切片在类型系统、内存布局和使用习惯上的显著差异。

一、长度是类型的一部分：不同长度数组不可混用

在Go语言中，数组类型由元素类型和长度共同决定，[3]int和[4]int是两个完全不同的类型。这一点与C、Java等语言存在明显不同。C语言里数组作为参数时容易退化为指针，Java的数组长度不参与静态类型判断，而Go编译器会在赋值、传参、类型转换等场景下严格检查数组长度是否一致。

举个例子，下面的代码会直接编译失败，因为等号两边的数组类型不一致。

package main
import "fmt"
func main() {
    var a [3]int
    var b [4]int
    a = b // 编译报错：cannot use b (type [4]int) as type [3]int in assignment
    fmt.Println(a, b)
}

这种严格性在类型安全上带来了好处，但也让数组用起来不够灵活。如果一个函数需要接收任意长度的整数序列，把参数写成[3]int显然不合适，应该使用切片[]int。同时要注意，不同长度的数组不仅不能赋值，也不能直接用==比较，因为可比较的前提是两边类型相同。这些编译期拦截可以避免很多运行期错误，但初次接触Go的开发者容易忽视长度在类型中的作用，从而在排错时耗费不少时间。

二、数组是值类型：赋值和传参都会整体复制

Go的数组是值类型，一个数组变量代表一整块连续内存，而不是指向首元素的指针。把数组赋给另一个变量，会复制所有元素；把数组传给函数，也会复制一份完整的数据。函数内部拿到的是一份副本，修改副本的元素不会影响原数组。

下面的代码展示了这种值复制行为。

package main
import "fmt"
func modify(arr [3]int) {
    arr[0] = 999
    fmt.Println("inside:", arr)
}
func main() {
    a := [3]int{1, 2, 3}
    modify(a)
    fmt.Println("outside:", a)
}

运行结果是函数内部打印[999 2 3]，而调用方打印[1 2 3]。这说明传入函数的数组确实是复制出来的独立副本。如果希望在函数内修改原数组，可以传递数组指针，例如把参数类型写成*[3]int，然后在函数内通过(*arr)[0]来修改。不过这种写法比较繁琐，实际开发中更多人会直接改用切片，因为切片传参虽然也是值传递，但复制的是切片头部结构，底层数组仍然是共享的，修改元素可以反映到原切片。

数组值复制还会带来性能问题。数组长度越大，赋值和传参时需要复制的元素就越多，频繁调用时开销明显。因此在需要传递较大序列数据时，使用切片或数组指针是更合理的选择。

三、数组与切片的核心行为差异

切片是Go中最常用的序列类型，它的底层结构包含指向数组的指针、长度和容量。切片传参时复制的是这个头部结构，而底层数组是共享的，所以函数内修改切片元素会直接影响原切片。这与数组整体复制的行为形成鲜明对比。

package main
import "fmt"
func modifySlice(s []int) {
    s[0] = 888
}
func main() {
    s := []int{1, 2, 3}
    modifySlice(s)
    fmt.Println(s) // [888 2 3]
}

另一个显著差异是动态性。数组长度固定，不能使用append函数，只能通过索引赋值。切片则支持append进行扩容，容量不足时会分配新的底层数组。从数组创建切片时，切片会引用原数组的一段连续区间，两者之间会形成共享关系。例如arr[1:3]创建的切片指向原数组的中间两个元素，修改切片会反过来影响原数组。

package main
import "fmt"
func main() {
    arr := [4]int{1, 2, 3, 4}
    s := arr[1:3]
    s[0] = 20
    fmt.Println(arr) // [1 20 3 4]
    fmt.Println(s)   // [20 3]
}

这种共享关系是很多混淆的根源。开发者常常以为切片是独立的数据副本，实际上它只是原数组的一个视图。只有在append导致底层数组重新分配后，切片才会脱离原数组。此外，数组不能为nil，声明后就有零值；切片则可以等于nil，其长度和容量都为0。在编写处理序列数据的通用逻辑时，需要特别注意这两者的nil判断差异。

四、常见混淆场景与排查建议

编译器报错cannot use ... as type ...通常是数组长度不匹配导致的。排查时先检查变量声明是否正确，尤其是函数参数表中是否多写或少写了长度。如果函数的意图是接受任意长度序列，应该把参数类型改成[]int，调用处也需要传入切片而不是数组。对于固定长度的数据结构，且元素数量不会变化，使用数组可以提供更好的内存连续性和编译期保证。

写函数修改数组却看不到效果时，先确认参数类型是数组还是切片。如果参数是[3]int，函数内部修改的只是副本；若确实需要修改原数组，可以改用切片参数，或者传指针*[3]int并记得解引用。排查时可以在函数内外打印变量地址，使用%p格式查看数组首元素的地址，判断是否指向同一块内存。

使用range遍历数组和切片时还有一个容易忽略的点：迭代变量是每个元素的副本。下面这段代码尝试在遍历时修改元素，但结果并没有生效。

package main
import "fmt"
func main() {
    a := [3]int{1, 2, 3}
    for i, v := range a {
        v = v * 10
        _ = i
    }
    fmt.Println(a) // [1 2 3]
    for i := range a {
        a[i] = a[i] * 10
    }
    fmt.Println(a) // [10 20 30]
}

第一个循环只是修改了副本变量v，没有影响原数组。第二个循环通过索引直接修改数组元素，才真正改变了数据。这个坑在遍历切片时同样存在，很多人误以为遍历切片时修改迭代变量会同步到切片本身，结果调试半天才发现问题。多维数组的类型中每个维度长度都参与类型判定，例如[2][3]int和[3][2]int不能混用。数组可以比较，但前提是类型相同且元素类型可比较，不同长度数组连比较的机会都没有，这些都需要在写代码时主动确认。