该用[]T，必须用[N]T仅当需栈上固定大小和值语义时；95%场景用切片，数组仅适用于密钥、坐标、颜色等小而固定结构。
什么时候该用 [N]T，什么时候必须用 []T
Go 里数组和切片是两种完全不同的类型，不能混用。比如你写 func f(arr [3]int)，传入 []int{1,2,3} 会编译报错：cannot use []int{...} as [3]int value in argument to f——因为 [3]int 和 []int 类型不兼容。
实际开发中，95% 的场景该用 []T：函数参数、返回值、JSON 解析结果、HTTP 响应体、配置列表……全都是切片。数组只适合极少数明确需要「栈上固定大小 + 值语义」的场合，比如：
-
[16]byte作 AES 密钥（长度固定、不能扩容） -
[2]float64表示二维坐标（小、可传值、无 GC 压力） -
[4]byte表示 RGBA 颜色（结构紧凑，可作 map key）
一旦你不确定长度、要追加元素、要传给标准库函数（如 json.Unmarshal、http.Post），就别碰数组，直接上 []T。
make([]T, len, cap) 的 len 和 cap 到底怎么设
len 是你“现在就要用多少个元素”，cap 是你“预计最多用多少个”。两者差值，就是还能 append 多少次而不触发扩容。
立即学习“go语言免费学习笔记（深入）”；
常见错误是只写 make([]int, 0)，然后反复 append：每次扩容都拷贝旧数据，小切片没事，但处理几千条日志或上万条记录时，性能断崖式下跌。
实操建议：
- 已知最终数量（比如解析出 127 条用户）：用
make([]User, 0, 127)，再循环append，零额外拷贝 - 不确定但有上限（比如 HTTP 请求 body 最大 1MB）：预估最大元素数，设
cap，避免突发大量append触发多轮扩容 -
len和cap相等（如make([]byte, 1024)）意味着一追加就扩容；若你后续只读不写，这种写法反而浪费内存
扩容本身不慢，但扩容后底层数组地址改变，所有共享该底层数组的切片都会“失联”——这点常被忽略。
append 后不重新赋值，为什么原切片没变
这是 Go 切片最经典的陷阱：append 返回的是一个新切片（可能指向新底层数组），它不会修改输入参数本身。
典型错误代码：
func addOne(s []int) {
append(s, 99) // ❌ 忘记接收返回值
}
s := []int{1, 2}
addOne(s)
fmt.Println(s) // 输出 [1 2]，不是 [1 2 99]
原因：函数内 s 是输入切片的副本（结构体拷贝：指针+长度+容量），append 可能分配新数组并返回新切片头，但没赋给任何变量，原 s 不受影响。
正确做法只有两个：
- 调用方自己接住：
s = append(s, 99) - 函数返回新切片：
func addOne(s []int) []int { return append(s, 99) }，调用时写s = addOne(s)
没有第三种方式。别指望“传引用就能改原变量”——Go 里没有引用传递，只有值传递，而切片的“值”里包含指针，所以能改元素，但改不了切片头本身。
截取大数组的子切片，为什么内存一直不释放
当你写 s := bigArray[:10]，s 确实只“看到”前 10 个元素，但它底层仍指向整个 bigArray。只要 s 还活着（比如被返回、被存进 map、被闭包捕获），整个大底层数组就无法被 GC 回收。
真实踩坑案例：
func loadConfig() []byte {
data := make([]byte, 10<<20) // 10MB
// ... 读文件到 data
return data[:128] // ❌ 只想要前 128 字节 header
}
结果：10MB 内存永远卡在堆上。
修复很简单，且成本极低：
- 用
append([]byte(nil), data[:128]...)—— 创建新底层数组并拷贝 - 或显式
copy：header := make([]byte, 128); copy(header, data)
这不是过度优化，是内存安全的基本操作。尤其在长期运行的服务中，这种“小切片拖大内存”的泄漏非常隐蔽。
