Golang通过指针避免大对象拷贝的方法
传指针能避免大结构体拷贝，因值传递会完整复制，而指针仅传地址（如64位系统8字节），开销恒定；但小结构体传值更优，且需防范nil解引用、并发安全及接口兼容性等问题。
传指针能避免大结构体拷贝，因值传递会完整复制，而指针仅传地址（如64位系统8字节），开销恒定；但小结构体传值更优，且需防范nil解引用、并发安全及接口兼容性等问题。为什么传指针能避免大结构体拷贝
Go 函数参数是值传递，struct 类型哪怕只有 1KB，每次调用都会完整复制一份。传 *MyStruct 后，实际只传 8 字节（64 位系统）的地址，开销恒定。这不是“引用传递”的语义，但效果上规避了拷贝成本。
注意：不是所有大对象都该传指针——小结构体（如 struct{a, b int}）传值反而更快，CPU 缓存更友好。
- 典型适合传指针的场景：
struct字段总大小 > 64 字节，或含[]byte、map、chan等内部堆分配字段 - 如果函数只读不写，且结构体可比较（如不含
map/slice），传值也安全；但编译器未必优化掉拷贝 - 方法接收者用指针（
func (s *MyStruct) Do()）才能修改原值，同时也自然避免拷贝
传指针时常见的 panic 场景
最常踩的坑是传了 nil 指针后直接解引用：
func process(s *LargeStruct) {
fmt.Println(s.Field) // panic: invalid memory address or nil pointer dereference
}
这在初始化未完成、channel 接收空值、或 map 查找不到键时极易发生。
- 务必在函数开头加
if s == nil { return }或明确文档要求非 nil - 构造函数返回
*T时，不要返回局部变量地址：return &localVar是错误的（逃逸分析会捕获，但逻辑易错） - 切片、map、channel 本身是指针包装类型，传它们不需要额外加
*；误传*[]int反而多一层间接，还可能引发同步问题
性能对比：什么时候指针真有收益
用 benchstat 测过真实场景：一个 256 字节的结构体，传值 vs 传指针，在循环 100 万次调用中，后者快约 3.2 倍；但若结构体只有 16 字节，两者差异在误差范围内（±1%）。
关键看逃逸分析结果：go build -gcflags="-m -m" 中出现 ... escapes to heap，说明值已逃逸，此时传指针反而减少栈分配压力。
- 用
go tool compile -S查看汇编，确认是否真生成了内存拷贝指令（如rep movsq） - 并发场景下，传指针意味着多个 goroutine 可能同时访问同一块内存，必须自行加锁或用
sync/atomic，这点比传值危险得多 - GC 压力：大量小对象传值 → 短生命周期栈分配；传指针 → 堆分配 → GC 扫描负担，需权衡
接口类型与指针接收者的隐含约束
如果某个方法定义在指针接收者上（func (p *T) String() string），那只有 *T 能满足该接口，T 值类型不能。
这意味着：即使你本意只是避免拷贝，一旦用了指针接收者，就锁死了调用方必须传指针——否则接口赋值失败，运行时报 cannot use t (type T) as type fmt.Stringer。
- 统一用指针接收者最省心，尤其结构体较大或后续可能需要修改字段时
- 如果确定永不修改、且结构体小（≤机器字长）、且要支持值类型赋值接口，才考虑值接收者
- 切勿混用：同一个结构体上部分方法用值接收者、部分用指针接收者，会导致接口实现不一致，极难调试
