Golang中的切片与数组差异_Golang切片与数组性能与使用场景

数组是值类型，赋值会拷贝全部元素；切片是轻量结构体，共享底层数组但易因修改相互影响，扩容时可能脱离共享，函数参数应依长度约束需求选择数组或切片。

数组是值类型，赋值会拷贝全部元素

go 中 []int 是切片，[5]int 才是数组。数组长度固定且属于值类型——每次传参或赋值都会复制整个底层数组。比如：

arr1 := [3]int{1, 2, 3} arr2 := arr1 // 复制全部3个int，arr2修改不影响arr1

这在大数组（如 [10000]int）场景下会明显拖慢性能，也容易引发意外的内存占用。而切片只是包含 ptr、len、cap 的轻量结构体，赋值只拷贝这三个字段。

切片共享底层数组，修改可能相互影响

这是最常踩的坑：多个切片指向同一底层数组时，一个改了，另一个可能“意外”变掉。例如：

data := []int{1, 2, 3, 4, 5} s1 := data[0:2] // [1 2] s2 := data[2:4] // [3 4] s1[0] = 999      // data 变成 [999 2 3 4 5]，s2[0] 现在是 3，没变；但若 s2 = data[1:3]，s2[0] 就会变成 2 → 被连带改掉

• 用 make([]T, len, cap) 显式分配新底层数组可避免共享
• 需要隔离数据时，用 append([]T(nil), s...) 或 copy(dst, src) 深拷贝
• 调试时可用 fmt.printf("%p", &s[0]) 查看底层数组首地址是否相同

切片扩容机制导致写入越界不报错，但行为不可靠

切片 append 超过 cap 时会自动分配新底层数组并复制数据。这个过程对调用方透明，但也带来两个隐患：

立即学习“go语言免费学习笔记（深入）”；

• 原切片和新切片不再共享底层数组，后续修改互不影响 —— 如果你依赖“共享”逻辑，就会出 bug
• 扩容策略由运行时决定（通常翻倍，但不保证），无法预测内存分配时机，对实时性敏感场景不利
• 没有越界 panic：写 s[i] 超过 len(s) 会 panic，但 append(s, x) 即使超出当前 cap 也不会 panic，只是悄悄换底层数组

高频追加场景建议预估容量，用 make([]T, 0, expectedCap) 初始化，减少扩容次数。

函数参数该用数组还是切片？看是否需强制长度约束

如果函数逻辑严格依赖固定长度（比如处理 RGB 像素、矩阵行、SHA256 校验和），用数组更安全：

func processRGB(c [3]uint8) { /* 编译期就限定必须传3个 */ } func processPixels(rows [][3]uint8) { /* 每行都是 [3]uint8 */ }

反之，绝大多数通用逻辑（遍历、过滤、聚合）应使用切片：

• 支持任意长度输入
• 调用方无需关心底层分配，传 []int、make([]int, n)、甚至字面量 []String{"a","b"} 都行
• 接口统一，便于组合（如配合 range、sort.Slice、strings.Fields 等）

数组作为参数本质是“类型即契约”，切片才是 Go 的默认数据载体。别为了“看起来紧凑”而用数组替代切片，除非长度语义本身是 API 的一部分。