Go值类型传参是浅层内存块拷贝：基本类型字段全复制，引用类型字段仅复制头部；结构体超64字节、高频调用或含大数组时应改用指针传参。

值类型传参时到底复制了什么

Go 中的 int、string、[8]byte、struct{} 等都是值类型，函数传参或赋值时会做「值拷贝」——但这个拷贝不是统一深度递归复制所有内容，而是按字段逐个复制内存块。关键区别在于：基本类型字段被真正复制，而引用类型字段（如 []byte、map[string]int、*T）只复制其头部（指针、len、cap 等），不复制底层数据。

• 例如 struct{ Name string; Tags []string } 传参：字符串底层数组和切片指向的元素数组都不会被复制，仅复制 Name 的字符串头（2 个 word）、Tags 的 slice header（3 个 word）
• 但 struct{ Data [1024]int } 传参会真实复制全部 1024 个 int，即 8KB（64 位系统）
• 所以“值拷贝 ≠ 深拷贝”，它更像“浅层内存块拷贝”

什么时候拷贝成本高到必须改用指针

拷贝开销是否可接受，核心看结构体大小和调用频率。Go 官方没有硬性阈值，但结合编译器行为和实测经验，以下情况建议直接用 *T：

• 结构体 unsafe.Sizeof(T{}) > 64 字节（常见于含大数组、多个嵌套结构或多个 string/[]T 字段）
• 该结构体在热路径（如 HTTP handler、循环内、高频 goroutine）中被频繁传参
• 结构体字段中包含 [N]byte（N ≥ 32）、[256]int 等固定大数组——数组是纯值类型，无法避免复制
• 你已通过 go build -gcflags="-m" main.go 发现该参数“escapes to heap”，说明栈上拷贝失败，被迫堆分配，GC 压力上升

type BigConfig struct {
    Hosts     [128]string
    Rules     []Rule
    Metadata  map[string]interface{}
    Buffer    [4096]byte
}
func process(c BigConfig) { / 每次调用都复制 ~8KB+ / }
// ✅ 应改为：func process(c *BigConfig)

值接收者方法 vs 指针接收者方法的性能陷阱

定义在 T 上的方法（值接收者）每次调用都会复制整个 T；而定义在 *T 上的则只传一个指针。这在大结构体上差异显著：

• 即使方法内部只读、不修改字段，只要 T 很大，值接收者仍会触发完整拷贝
• 如果该类型已有至少一个指针接收者方法，为保持方法集一致和接口兼容性，其余方法也应统一用指针接收者
• 小结构体（如 type Point struct{ X, Y int }）用值接收者没问题，甚至更利于内联和寄存器优化
• 不要因为“想保证不可变”就盲目用值接收者——Go 中不可变靠设计约束，不是靠拷贝防御

容易被忽略的逃逸与栈分配真相

很多人以为“值类型一定在栈上”，其实不然。逃逸分析才是决定分配位置的关键。即使你写的是 func f(s SmallStruct)，一旦编译器发现该参数被取地址、返回、或闭包捕获，它就会逃逸到堆上——这时不仅没省下拷贝，还额外增加了 GC 开销。

• 验证方式：加 -gcflags="-m -l" 编译，搜索 “moved to heap” 或 “escapes”
• 常见诱因：把参数传给 fmt.Printf、作为 channel 发送值、赋给全局变量、参与 goroutine 启动
• 小对象传指针未必更差，但大对象传值几乎总是更差——尤其当它同时触发逃逸时，等于“既拷贝又堆分配”

真正需要警惕的不是“要不要用指针”，而是“这个值在当前上下文中是否会被复制 + 是否逃逸”。性能优化得从 go tool compile 输出和 benchstat 对比出发，而不是凭感觉选 T 还是 *T。