Go中数组传参会整块复制，大数组导致性能下降；应传指针*[N]T或校验切片长度，避免隐式转换和无效拷贝。
数组传参就是整块复制，大数组一传就卡
Go 语言中 [1024]int 这样的数组是值类型，函数调用时会把全部 1024 个 int（共 8KB）从调用栈拷贝到被调函数栈帧里。这不是指针传递，也不是“传引用”，是实打实的内存块复制 —— 和你写 a := b 一样，整个结构体化地搬过去。
- 数组长度越大，拷贝越慢；1MB 数组传一次 ≈ 1MB 内存搬运 + 栈空间占用
- 编译器不会帮你优化掉这个拷贝，哪怕函数里只读不写
- 逃逸分析显示：
arr does not escape是好事，但前提是它真没逃逸；一旦你把它转成[]int传给别的函数，立刻触发逃逸到堆上
用指针传数组才是正解，不是“可选”，是“必须”
想避免拷贝？唯一干净做法是传指针：*[1024]int。它只传 8 字节地址，和传 *[]int 或 *struct{...} 一个道理。
- 函数签名必须显式声明为指针类型：
func process(arr *[1024]int)，不能写func process(arr [1024]int) - 调用时加
&：process(&myArr)，否则编译报错或意外值拷贝 - 若数组长度不固定或需泛型适配，别硬扛数组类型 —— 改用切片
[]int，并确保调用方控制好底层数组生命周期
误用切片接口导致长度丢失和越界风险
很多人把 [5]int 直接传给接收 []int 的函数，以为只是“换个写法”。实际发生了隐式转换：arr[:] → []int，原始长度信息（5）彻底丢失，函数内只能靠 len() 动态判断 —— 而这个长度完全取决于调用方怎么切，极易出错。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 错误现象：函数逻辑依赖“一定是 5 个元素”，结果收到
[]int{1,2}，后续访问arr[3]panic - 更隐蔽的问题：多个函数交替操作同一底层数组，但没人知道谁在哪个索引范围写入
- 正确做法：要么坚持用固定长度数组类型传参（保证类型安全），要么在切片入口加校验：
if len(arr) != 5 { panic("expected 5 elements") }
copy() 不是万能钥匙，数组转切片有代价
想拷贝数组内容？copy(dst[:], src[:]) 是对的，但前提是 dst 和 src 都已分配好。如果为了“传参+修改”而先 copy 出一份新数组再传指针，等于绕远路做两件事：先拷贝、再传址 —— 白费一次内存操作。
- 常见陷阱：在循环里反复
dst := [1024]int{}; copy(dst[:], src[:])，每次都在栈上分配 + 拷贝，性能雪崩 - 真正需要隔离副本时，优先复用：用
sync.Pool缓存大数组，或全局预分配（如var bufPool = sync.Pool{New: func() interface{} { return new([1024]int) }}） - 若只是临时读取，且能确保原数组生命周期覆盖使用期，直接传
*[N]T指针最轻量
数组传参效率低这件事，本质不是 Go 的缺陷，而是它把“值语义”执行得很彻底。问题不在你怎么写，而在你有没有意识到 —— 那个看似普通的 func f(a [10000]int)，背后是一次沉默的千次内存拷贝。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
