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
}
<p>func process(c BigConfig) { /<em> 每次调用都复制 ~8KB+ </em>/ }
// ✅ 应改为：func process(c *BigConfig)</p>值接收者方法 vs 指针接收者方法的性能陷阱
定义在 T 上的方法（值接收者）每次调用都会复制整个 T；而定义在 *T 上的则只传一个指针。这在大结构体上差异显著：
- 即使方法内部只读、不修改字段，只要
T很大，值接收者仍会触发完整拷贝 - 如果该类型已有至少一个指针接收者方法，为保持方法集一致和接口兼容性，其余方法也应统一用指针接收者
- 小结构体（如
type Point struct{ X, Y int }）用值接收者没问题，甚至更利于内联和寄存器优化 - 不要因为“想保证不可变”就盲目用值接收者——Go 中不可变靠设计约束，不是靠拷贝防御
容易被忽略的逃逸与栈分配真相
很多人以为“值类型一定在栈上”，其实不然。逃逸分析才是决定分配位置的关键。即使你写的是 func f(s SmallStruct)，一旦编译器发现该参数被取地址、返回、或闭包捕获，它就会逃逸到堆上——这时不仅没省下拷贝，还额外增加了 GC 开销。
立即学习“go语言免费学习笔记（深入）”；
- 验证方式：加
-gcflags="-m -l"编译，搜索 “moved to heap” 或 “escapes” - 常见诱因：把参数传给
fmt.Printf、作为 channel 发送值、赋给全局变量、参与 goroutine 启动 - 小对象传指针未必更差，但大对象传值几乎总是更差——尤其当它同时触发逃逸时，等于“既拷贝又堆分配”
真正需要警惕的不是“要不要用指针”，而是“这个值在当前上下文中是否会被复制 + 是否逃逸”。性能优化得从 go tool compile 输出和 benchstat 对比出发，而不是凭感觉选 T 还是 *T。
