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