数组是值类型，传参时整块复制；切片传的是含指针、len、cap的结构体，共享底层数组。[3]int与[4]int类型不同，而[]int无长度限制，可接收任意长度切片。
数组是值类型，传参时整块复制，切片传的是“视图结构体”
当你把一个 [5]int 传给函数，Go 会把这 5 个整数完整拷贝一份——哪怕只读，也开销不小；而传 []int 时，实际只拷贝一个含三个字段的结构体：array（指针）、len、cap。这意味着切片修改可能影响原底层数组，但结构体本身是值拷贝。
- 常见错误：以为
s2 = s1后修改s2不会影响s1→ 实际上它们共享底层数组，改元素会互相可见 - 正确做法：如需隔离，用
append([]int(nil), s1...)或copy到新切片 - 性能提示：大数组别直接当参数传；小数据量下差异可忽略，但习惯用切片更安全
长度是否属于类型？这是类型系统里最硬的分水岭
[3]int 和 [4]int 是完全不同的类型，不能赋值、不能比较、不能混用；而 []int 就是 []int，不管它背后是 3 个还是 300 个元素。
- 典型报错：
cannot use arr (variable of type [5]int) as [3]int value in assignment - 接口兼容性：函数参数写
func f(s []int)可接收任意长度切片；若写func f(a [5]int)，只能传严格匹配的数组 - 零值差异：
var a [3]int的零值是[3]int{0,0,0}；var s []int的零值是nil（注意：len(s)和cap(s)都为 0，但s == nil为 true）
扩容机制让 slice 看似“无限”，但底层数组其实很诚实
slice 没有自己存数据，它只是底层数组的一段窗口。append 超过 cap 时，Go 会分配新数组、复制旧数据、更新指针——这个过程不可见，但代价真实存在。
- 容易踩的坑：
s := make([]int, 0, 4); s = append(s, 1,2,3,4,5)→ 第 5 次append触发扩容，原底层数组被丢弃，后续所有基于旧s的切片（如s[1:]）仍指向老内存，但内容已不再更新 - 查容量用
cap(s)，不是len(s)；扩容策略通常是翻倍（小容量）或加固定值（大容量），具体看 runtime 源码 - 预估容量能省掉多次 realloc：比如知道要塞 100 个元素，就用
make([]int, 0, 100)
何时非用数组不可？真不多，但有且仅有的几个场景
绝大多数业务代码里，你几乎不需要显式声明数组。但以下情况例外：
立即学习“go语言免费学习笔记（深入）”；
- 作为结构体字段且需固定大小（比如 IPv4 地址：
type IP [4]byte），此时数组长度是类型一部分，能保证内存布局稳定 - 需要栈上分配小块确定空间（
[16]byte常用于临时缓冲），避免堆分配和 GC 压力 - 用作 map 的 key（数组可比较，
[]byte不行）：m := map[[4]byte]int{[4]byte{1,2,3,4}: 1} - 调用 C 函数时需传递 C 数组（
C.array对应 Go 中的[N]C.type）
package main
import "fmt"
func main() {
// 数组：类型含长度，传参即拷贝
a := [3]int{1, 2, 3}
modifyArray(a) // a 不变
fmt.Println(a) // [1 2 3]
// 切片：传结构体，改元素影响底层数组
s := []int{1, 2, 3}
modifySlice(s) // s[0] 变成 999
fmt.Println(s) // [999 2 3]
}
func modifyArray(a [3]int) { a[0] = 999 }
func modifySlice(s []int) { s[0] = 999 }
底层数组是否被共享、扩容是否发生、类型能否匹配——这些不是“理论区别”，而是每次写 append、传参、赋值时实实在在影响行为的点。别依赖直觉，该打日志打日志，该查 cap 查 cap。 
