go中数组传参未变是因为值传递拷贝副本；大数组应改用指针或切片，小数组和基础类型值传递更高效；结构体依大小和字段特性选择传值或指针。
Go 里数组传参为什么看起来没变？
因为数组是值类型，传参时整个数组被完整拷贝——但你改的只是副本。常见错误是以为 func modify(arr [3]int) 能修改原数组，结果调用后原数组毫发无损。
实际场景：想在函数里填充一个固定长度的缓冲区（比如 [64]byte），又不想让调用方看到中间状态。这时值传递反而是安全的。
注意点：[1024]int 这种大数组传参开销明显，编译器不会优化掉拷贝；而 []int（切片）传参只拷贝 header（24 字节），代价小得多。
- 要修改原数组 → 改用指针：
func modify(arr *[3]int - 要避免拷贝且需动态长度 → 用切片：
func process(data []byte) - 小数组（≤8 字节，如
[2]int）拷贝成本可忽略，值传递更直观
结构体传参时，什么时候该加 *？
结构体也是值类型，但大小差异极大：空结构体 struct{} 拷贝零成本；带多个字段的大结构体（如含 []byte、map[string]int）拷贝的是 header，不是底层数组或哈希表本身——但结构体自身字段仍被复制。
立即学习“go语言免费学习笔记（深入）”；
典型坑：type Config struct { Timeout time.Duration; Hosts []string }，传值时 Hosts 的 slice header 被拷贝，但底层 []string 数据没复制；可读可写，但追加元素（append）会生成新底层数组，原结构体字段不变。
- 需要修改结构体字段 → 必须用指针：
func (c *Config) SetTimeout(d time.Duration) - 只读访问且结构体 ≤ 16 字节（如两个
int64）→ 值传递更高效，避免解引用开销 - 含指针字段（如
*http.Client）的结构体，值传递不影响其指向对象，但要注意竞态（多个 goroutine 同时改同一*http.Client）
基础类型（int/float/bool/string）传参有性能陷阱吗？
没有。所有基础类型都是值类型，拷贝成本固定且极低：int64 是 8 字节，string 是 16 字节（2 个 word：ptr + len）。哪怕传 string，也只是拷贝头，不拷贝底层字节数组。
唯一例外是 string 的意外修改：因为字符串不可变，任何“修改”（如切片、拼接）都会分配新底层数组。但这和传参无关，是语义决定的。
-
string传参比[]byte更轻量（后者 header 是 24 字节） -
interface{}传参会触发装箱：若底层是大结构体，装箱时仍要拷贝值，不是只拷贝指针 - 别为了“省拷贝”把
int改成*int——解引用+内存分配反而更慢
如何快速判断某个类型传参是否划算？
看运行时大小：unsafe.Sizeof(x) 是最直接的方式。值传递成本 ≈ unsafe.Sizeof(T) 的内存拷贝 + 寄存器/栈搬运开销。
常见参考值（64 位系统）：int/int64 是 8 字节，string 是 16 字节，struct{a, b int} 是 16 字节（无 padding），[1000]int 是 8000 字节——这时候不加 * 就是自找麻烦。
- 不确定大小？在关键路径上加
go tool compile -S yourfile.go看汇编，搜MOVQ或大块REP MOVSQ - 结构体字段多但很多是零值？用
go vet -shadow检查是否误传了未初始化的大字段 - 第三方库返回的结构体（如
net/http.Request）？别猜，查文档或源码——它通常设计为值传递安全，但内部含指针
真正容易被忽略的，是嵌套结构体中隐藏的大数组或切片字段：表面看 unsafe.Sizeof 不大，但一调用方法就触发深层拷贝。这种得靠 profiling 工具抓 runtime.allocs_inuse_objects 才能暴露。
