struct值传递会引发大对象拷贝，因Go中所有参数均为值传递，传参时完整复制所有字段；含大数组、嵌套结构等会导致KB级memcpy开销，应优先使用指针传递避免拷贝。
为什么 struct 值传递会引发大对象拷贝？
Go 中所有参数都是值传递，struct 变量传参时会完整复制其所有字段。如果结构体包含大量字段、嵌套结构、或内含大数组（如 [1024]byte）、切片底层数组（注意：切片头是小的，但若误认为它“代表整个数据”就容易出错）、字符串底层数据等，一次调用就可能触发数百字节甚至 KB 级内存拷贝。这不是 GC 问题，而是栈/堆上实实在在的 memcpy 开销。
常见误判场景：
- 把 type Config struct { Data [8192]byte } 直接作为函数参数
- 在循环中频繁传入含大字段的临时 struct{ A [1000]int; B string }
- 使用 interface{} 包装大结构体，触发接口内部的值拷贝
用指针替代值传递是最直接的解法
将接收方签名从 func process(s MyBigStruct) 改为 func process(s *MyBigStruct)，能彻底避免结构体内容拷贝——只传 8 字节（64 位系统）地址。但要注意副作用：
- 调用方必须确保传入指针指向有效内存（不能是
nil，除非函数明确支持） - 被调函数获得写权限，可能意外修改原值；若只需读，应在文档或函数名中体现，例如
processReadOnly - 逃逸分析可能让原结构体提前分配到堆上（可用
go build -gcflags="-m"验证）
示例对比：
type Packet struct {
Header [16]byte
Payload [65536]byte // 64KB
}
// ❌ 每次调用拷贝 64KB+
func handle(p Packet) { / ... / }
// ✅ 只传指针，无拷贝
func handle(p Packet) { / ... */ }
切片和字符串本身已是“轻量引用”，别画蛇添足取地址
切片（[]byte）、字符串（string）在 Go 运行时表示为 header 结构（含指针、长度、容量/长度），本身仅 24 字节。直接传值没有性能负担，反而是最佳实践。
立即学习“go语言免费学习笔记（深入）”；
错误做法：
- func f(data *[]byte) —— 多一层指针，且易引发混淆
- func f(s *string) —— 完全没必要，还增加 nil 判断成本
正确姿势：
- func f(data []byte) 和 func f(s string) 是标准、高效、清晰的写法
- 若需修改切片长度/容量（如 append 后返回新切片），函数应返回新切片，而非试图通过指针修改原变量
零拷贝场景下考虑 unsafe.Slice 或 reflect.SliceHeader（慎用）
当处理超大内存块（如 mmap 文件、GPU 显存映射），且必须避免任何数据复制时，可绕过 Go 类型系统构造视图。但这属于高危操作，仅限极少数底层库（如 io_uring 绑定、高性能网络协议栈）使用。
关键约束：
- unsafe.Slice(ptr, len) 不做内存所有权检查，ptr 必须指向合法可访问内存，且生命周期必须长于切片使用期
- 禁止对 unsafe.Slice 返回的切片做 append，否则可能越界或破坏原有内存布局
- 生产环境务必加 //go:systemstack 注释并充分测试，CI 中开启 -gcflags="-d=checkptr"
典型误用点：把局部数组地址传给 unsafe.Slice，函数返回后该内存已失效。
真正难的不是选指针还是值，而是在接口设计初期就判断清楚：这个结构体是否会被高频传递？它的尺寸是否稳定？调用方是否需要隔离修改？很多拷贝问题其实在定义 type 的那一刻就埋下了。
