Go中结构体数组传参时，[N]T为值拷贝整个数组，[]T仅拷贝切片头（指针、长度、容量），修改元素影响原数据，但append扩容或赋值map/slice字段不影响原值。
结构体数组传参时到底传的是什么
Go 语言中，[]struct{} 是切片，不是数组；而 [N]struct{} 才是真正的数组。很多人说“结构体数组传参会拷贝”，其实得先分清你传的是切片还是数组。
切片本身是三元组（底层数组指针 + 长度 + 容量），传参时只拷贝这三个字段，不拷贝底层数组数据——所以修改切片元素会影响原数据；但若在函数内用 append 导致扩容，就可能指向新底层数组，原切片不受影响。
-
[5]User这种固定长度数组传参会完整拷贝全部结构体字段（值拷贝） -
[]User传参只拷贝切片头，不拷贝元素，但元素地址共享 - 如果结构体里有指针、
map、slice、chan或func字段，这些字段的值（即地址）仍会被拷贝，但它们指向的数据不会被复制
为什么改了参数里的 struct 字段，主函数没变
常见现象：把 [3]Point 传进函数，函数里改 p[0].x = 100，返回后主函数里还是旧值。这是因为整个数组被值拷贝了，函数里操作的是副本。
示例：
立即学习“go语言免费学习笔记（深入）”；
func modifyArr(arr [2]struct{ x int }) {
arr[0].x = 999 // 不会影响调用方
}
解决办法只有两个：
- 改用指针数组：
*[2]struct{ x int }（不常用） - 更实际的是换用切片：
[]struct{ x int }，再配合索引修改（因为底层数组共享） - 或者直接传
*[N]T，但要注意调用时取地址：modifyArr(&myArr)
结构体内含 slice/map 时的“浅拷贝”陷阱
哪怕你传的是 []User 切片，只要 User 里有 Roles []string 这种字段，函数内执行 u.Roles = append(u.Roles, "admin") 就可能触发扩容，导致该字段指向新底层数组——此时主函数看到的 Roles 还是原来的，长度也没变。
更隐蔽的是：
-
u.Roles[0] = "root"—— ✅ 会反映到原 slice（同底层数组） -
u.Roles = []string{"root"}—— ❌ 原 slice 完全不变（只是改了副本的指针） -
u.Meta = map[string]int{"a": 1}—— ❌ 原 map 不受影响（map 变量本身是 header 拷贝）
这类问题不会报错，但逻辑出错极难定位。
性能敏感场景下怎么选：数组 vs 切片 vs 指针
小结构体（如 [4][3]float64 矩阵）、确定长度且不增删，用数组 + 指针传参最稳：*[16]float64 避免拷贝，语义也明确。
常规业务逻辑，优先用 []T，它灵活、标准库适配好，且多数情况不需要担心拷贝开销——真正耗资源的是结构体字段里的大 slice 或 map，不是切片头。
- 避免写
func f(arr [1024]Event)—— 一次拷贝 1024×结构体大小，容易栈溢出 - 如果只读，且结构体小，传值没问题；如果要写，优先考虑
func f(arr []T)或func f(arr *[N]T) - 用
go tool compile -S看汇编，能确认是否真发生了大块内存拷贝
真正容易被忽略的，是结构体字段本身的可变性——不是传参方式错了，而是没意识到 map 和 slice 字段的赋值行为根本不会穿透到原值。
