go中结构体传值会完整拷贝内存，含slice/map或≥64字节时触发runtime.memmove，应优先传指针；小结构体（≤8字节且无引用类型）传值更安全高效，需结合大小、字段类型与语义判断。
Go 里传结构体值不是“慢”，而是“复制整个结构体”——只要它大于几个字节，或者含 slice、map、[]byte 这类字段，每次调用函数或赋值，就真正在内存里搬一次数据。这不是延迟问题，是实打实的 CPU 和堆分配开销。
pprof 显示 runtime.memmove 占比飙升，说明你在反复拷贝
这是最直接的信号：你写的函数接收一个结构体值参数，而这个结构体实际大小远超栈上高效搬运的范围（比如 ≥64 字节），Go 编译器会生成 runtime.memmove 调用完成深拷贝。
- 用
go build -gcflags="-m" main.go查看编译日志，如果看到类似... escapes to heap或... moved to heap，说明该值已逃逸，拷贝成本更高 -
go tool pprof采样后执行top，若runtime.memmove排前三，基本可锁定是结构体值传递在作祟 - 特别注意：哪怕结构体只含一个
[]int字段，拷贝时只复制 slice header（24 字节），但语义上仍可能意外共享底层数组——你以为隔离了，其实没隔离
结构体含 slice/map 时，传值 ≠ 隔离，这是最大认知陷阱
很多人以为 func f(cfg Config) 就能安全修改 cfg 内部字段而不影响原值，但只要 Config.Data []string，你就可能踩坑：
-
cfg.Data = append(cfg.Data, "x")→ 通常不改原 slice（因为 append 可能扩容） -
cfg.Data[0] = "y"→ 直接改原底层数组，原cfg的Data[0]立刻变 -
cfg.NestedMap["key"] = val→ 同样改的是原 map 底层哈希表 - 真正想隔离？必须手动深拷贝：
newData := make([]string, len(cfg.Data)); copy(newData, cfg.Data)
什么时候该果断改用 *T，而不是靠感觉猜
别纠结“8 字节还是 16 字节”，按这几条硬标准判断：
- 结构体字段中任意一个是
slice、map、chan、func、interface{}→ 必须传指针，否则语义不可控 - 结构体大小 ≥64 字节（
unsafe.Sizeof(T{})可查）→ 传指针更稳，避免跨 cache line 拷贝 - 方法名含
Update、Set、Configure等动词 → 用户预期副作用，值接收器根本改不动原值 - 结构体嵌入了
sync.Mutex或其他不可拷贝类型 → 值传递直接编译失败，只能用指针
接口赋值时传值还是传指针，决定的是零拷贝还是整块复制
当你把结构体塞进 io.Writer、json.Marshaler 这类接口，传法不对，性能就废了一半：
-
var w io.Writer = &bytes.Buffer{}→ 接口data字段存地址，零拷贝 -
var w io.Writer = bytes.Buffer{}→ 整个Buffer（含内部buf []byteheader）被复制进接口，后续w.Write()操作的是副本 - 函数参数是
func save(w io.Writer)，调用save(myBuf)（myBuf是值）→ 复制发生在此刻，不是在save函数体内 - 导出结构体实现接口时，优先用指针接收器：
func (b *Buffer) Write(p []byte)，这样无论传b还是&b都能正确绑定
最常被忽略的一点：指针本身不保证线程安全，也不自动解决逃逸。传 *BigStruct 能省拷贝，但如果把它存进全局 map[string]*BigStruct 或返回给调用方，很可能让本可栈分配的对象被迫上堆——得用 -gcflags="-m -l" 确认逃逸路径，再决定是否值得换指针。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
