数组长度是类型的一部分，切片不是；声明[3]int和[4]int不兼容，不能赋值；切片[]int类型统一，可自由传参；除非需固定长度语义，否则函数参数一律用[]T；数组传参拷贝全部元素，切片只拷贝24字节header。
数组长度是类型的一部分，切片不是
这是最直接影响编译和赋值行为的区别。声明 [3]int 和 [4]int 是两个完全不兼容的类型，不能互相赋值或传参：
-
var a [3]int和var b [4]int——a = b直接报错：cannot use b (variable of type [4]int) as [3]int value -
[]int无论背后是 5 个还是 500 个元素，类型始终是[]int，可自由赋值、传参、返回
所以函数参数该用数组还是切片？除非你**明确需要固定长度语义**（比如处理 16 字节 UUID 或 RGB 像素），否则一律用 []T —— 否则每次改个长度就得改函数签名。
传参时数组拷贝整个内存，切片只拷贝头结构
数组是值类型，传参即复制全部元素；切片是引用类型，传参只复制 24 字节的 header（指针 + len + cap）：
- 传
[1000]int进函数：栈上拷贝 8KB（假设 int64），开销大且无必要 - 传
[]int进函数：只拷贝 header，原底层数组仍在堆上，修改元素会影响调用方
注意：这不是“传引用”或“传指针”的语法糖，而是底层结构决定的——slice 结构体里本身就含指针字段。所以别写 *[]int，那是套娃，通常没意义。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
切片的 len 和 cap 必须分清，扩容行为藏在 cap 里
len 是当前元素个数，cap 是从起始位置到底层数组末尾还能塞多少——它决定了 append 是否触发 realloc：
-
s := make([]int, 3, 5)→len=3,cap=5，再 append 2 个不会扩容 -
s := []int{1,2,3}→len=3,cap=3，append 第 4 个就分配新数组并拷贝 -
s[3:5]这种切片表达式会改变cap（新cap = 原 cap - 起始索引），但不改变底层数组
常见坑：从大数组切出小切片后长期持有，导致整个底层数组无法被 GC 回收——这时该用 copy 构造独立副本。
用 make 还是字面量？看是否需要预分配容量
两种初始化方式语义不同：
-
s := []int{1,2,3}：长度 = 容量 = 元素个数，适合已知初始值且后续增删不频繁 -
s := make([]int, 0, 100)：长度为 0，容量为 100，适合要反复append但能预估上限的场景（避免多次扩容拷贝）
别写 make([]int, 100) 然后手动填值——这会初始化 100 个零值，再覆盖，纯属浪费。真要预占空间又不想初始化，就用 make 指定 cap，再用 s = s[:0] 清空长度。
真正容易被忽略的点：切片的“引用性”不是魔法，它依赖底层数组存在；一旦底层数组被回收（比如原数组变量超出作用域且无其他引用），而你又通过切片访问了它——Go 的 runtime 会 panic，但这种 bug 往往延迟暴露，得靠 go vet 或静态分析工具提前揪出来。
