Golang数组传参为什么性能差_数组值传递问题分析
Go数组传参是值传递，会完整复制整个内存块；应优先使用slice（仅传24字节）替代，大数组必须用指针传递或堆分配。
Go 数组传参是值传递，复制整个内存块
Go 语言中，[5]int、[1024]byte 这类固定长度数组作为函数参数时，会完整复制所有元素到栈上。这不是指针传递，也不是引用传递——编译器生成的指令会逐字节拷贝整个数组内存区域。
常见错误现象：func process(arr [10000]int) 调用时卡顿、栈空间暴涨、逃逸分析显示大量栈分配；而换成 []int 后性能立刻
- 数组大小直接决定拷贝开销：一个
[10000]int在 64 位系统上占 80 KB，每次调用都复制一次 - 栈空间可能溢出：默认 goroutine 栈初始仅 2 KB，大数组传参会触发栈扩容甚至 panic
- 无法被编译器优化掉：即使函数内只读取第一个元素，整个数组仍会被复制
用 slice 替代数组传参是标准解法
[]T 是运行时动态结构，底层仅包含三个字段：ptr（指向底层数组的指针）、len、cap，共 24 字节（64 位平台）。传 slice 就是传这 24 字节，和传一个 struct 一样轻量。
使用场景：任何需要“把一组数据交给函数处理”的地方，只要不强制要求类型为数组，就该用 slice。
- 函数签名应写成
func f(data []int)，而非func f(data [100]int) - 调用时可直接传切片：
f(mySlice)；若只有数组变量arr := [5]int{1,2,3,4,5}，用f(arr[:])转换 - 注意
arr[:]生成的 slice 仍指向原数组内存，修改会影响原数组（这是预期行为）
什么时候必须用数组？以及如何安全传参
必须用数组的典型场景：需要类型精确匹配（如哈希计算 [32]byte）、C 交互（C.struct 成员）、或利用数组长度作为类型一部分做编译期检查（如状态机 transition 表）。
此时传参不能硬扛大数组，得绕过值传递：
- 传指针：
func f(p *[1000]int，调用时用f(&arr)—— 只传 8 字节地址 - 避免在栈上分配大数组：把大数组声明为包级变量或 new 分配在堆上，再传指针
- 确认是否真需要数组：比如
[16]byte做 UUID，用[16]byte没问题；但[65536]byte做缓冲区，几乎一定该用[]byte或*[65536]byte
逃逸分析能帮你发现隐式复制问题
用 go build -gcflags="-m -l" 查看编译器对变量的逃逸判断。如果看到类似 "moved to heap: arr" 或 "can not inline: ... large stack frame"，往往说明你在无意中触发了大数组复制。
示例对比：
func bad(arr [1000]int) { fmt.Println(arr[0]) }
func good(s []int) { fmt.Println(s[0]) }
运行 go build -gcflags="-m -l" main.go 会发现 bad 函数里 arr 很可能逃逸到堆，或导致栈帧过大警告；而 good 完全无此问题。
真正容易被忽略的是：数组长度一旦超过几十个元素，性能退化就非常明显，但开发者常以为“只是多几个 int”，没意识到底层是整块 memcpy。
