值类型复制成本取决于拷贝字节数与调用频次的乘积；用 unsafe.Sizeof() 估算结构体头部大小（如 User{} 为40/48字节），≤16字节基本无感，≥64字节或含大数组/map/slice时应警惕指针传参。
值类型复制成本是否高，取决于你传的是什么、多大、多频繁——不是“高”或“低”的绝对判断，而是“拷贝字节数 × 调用频次”是否已构成瓶颈。
怎么快速估算一个结构体的拷贝成本
用 unsafe.Sizeof() 看内存占用，是第一步也是最关键的一步：
type User struct {
ID int64
Name string
Email string
Tags []string
Meta map[string]interface{}
}
fmt.Println(unsafe.Sizeof(User{})) // 输出通常是 40 或 48 字节（不含底层数组/哈希表数据）
注意：这里只算结构体头部大小（如 string 是 16 字节，[]string 是 24 字节），不包含 Tags 底层数组或 Meta 哈希桶的内存。但只要结构体本身 ≥ 64 字节，或含大数组（如 [1024]byte），就该警惕。
- ≤ 16 字节（如
int、time.Time、2 字段小 struct）：基本无感，值传参更干净 - 16–64 字节（如带 3–5 字段、无 slice/map 的 struct）：热路径上可测，通常仍可接受
- ≥ 64 字节，或含
[N]byte（N > 32）、map、大slice字段：大概率需要指针传参
函数参数传值 vs 传指针：哪些场景必须换
不是“越大越要指针”，而是看「是否被高频读写 + 拷贝是否压垮调用栈」。常见触发点：
立即学习“go语言免费学习笔记（深入）”；
- HTTP handler 里每次请求都 new 一个大 struct 并传值给
validate()、save()等函数 - 循环内调用（如
for _, u := range users { process(u) }），且process参数是 128 字节 struct - 函数返回值是大 struct（如
func getConfig() Config），且调用方又立即赋值给新变量 —— 此时发生两次拷贝（返回 + 赋值） -
go build -gcflags="-m" main.go显示某 struct “escapes to heap”，说明它本可栈分配，却因值拷贝被迫堆化，GC 压力上升
这时把 func process(u User) 改成 func process(u *User)，往往能让 runtime.memmove 在 pprof 中下降 30%+。
传指针的隐藏代价：别为了省拷贝反而拖慢程序
指针不是银弹。解引用、GC 跟踪、缓存局部性都会反向影响性能：
- 小 struct（如
type Point struct{ X, Y float64 }，仅 16 字节）传指针，反而多一次内存访问，还让变量更容易逃逸到堆 - 如果函数只读不写，且调用不频繁（如配置初始化只执行一次），值传参语义更清晰，调试也更安全
-
*[1000]int虽然只传 8 字节，但后续所有访问都要解引用；而[1000]int在栈上连续布局，遍历时 CPU 缓存预取更友好 - 结构体含
slice字段时，值传参会复制 header（3 个 word），但底层数组共享 —— 这种“半共享”行为容易引发并发修改 bug，比纯值拷贝更难排查
真正要盯住的，不是“该不该用指针”，而是「这个拷贝有没有出现在火焰图热点里」「pprof 显示 memmove 占比是否异常高」「逃逸分析有没有意外堆分配」——优化永远从实测开始，而不是凭感觉改 *。
