传大结构体优先用指针，因值传递会复制整个内存块，引发高GC压力和性能下降；指针仅传8字节地址，开销恒定，但需防范nil解引用和并发写风险。
为什么传大结构体时要优先用指针
Go 函数参数是值传递，每次传入一个结构体都会复制整个内存块。如果结构体含大量字段、嵌套切片或 map（比如 type User struct { ID int; Name string; Profile map[string]interface{}; Posts []Post }），一次调用可能触发 KB 级拷贝，GC 压力陡增，性能明显下降。
用指针传参本质上传的是地址（通常 8 字节），无论结构体多大，开销恒定。但要注意：指针带来可变性风险，调用方原始数据可能被意外修改。
- 结构体字段超过 4–5 个基础类型，或含任意
[]byte、map、slice、string，就该考虑指针 - 只读场景（如日志打印、校验逻辑）仍建议用指针 + 显式注释说明“不修改”，避免无谓拷贝
- 若结构体小（如仅 2–3 个
int/bool），值传递反而更清晰，且现代编译器可能优化掉部分拷贝
方法接收者该用值还是指针
接收者类型决定方法能否修改原始实例，也影响调用时的拷贝行为。错误选择会导致编译失败或静默性能问题。
- 只要方法内有赋值给
receiver.field的语句，接收者必须是指针类型（func (u *User) UpdateName(n string) {...}），否则报错cannot assign to u.Name in method call - 即使方法只读，若结构体较大，也应声明为指针接收者——否则每次调用都拷贝整个结构体
- 混用值/指针接收者会导致同一类型出现两个“不兼容”的方法集：值接收者方法可被值和指针调用；指针接收者方法只能被指针调用。若你导出结构体并供他人使用，统一用指针接收者最安全
逃逸分析与指针分配的实际影响
用指针不一定等于堆分配。是否逃逸取决于变量生命周期是否超出当前函数作用域。盲目加 & 可能让本可栈存的变量被迫堆分配，增加 GC 负担。
立即学习“go语言免费学习笔记（深入）”；
用 go build -gcflags="-m -l" 查看逃逸分析结果：
./user.go:12:6: &u moves to heap: field of local variable u
- 如果结构体在函数内创建、只在本函数内使用，且没取地址传给其他函数或返回，它大概率栈分配——此时用值传参反而更高效
- 一旦取地址（
&u）并传给其他函数、存入全局变量、或作为返回值，就会逃逸到堆，这时指针传参已成必然 - 不要为了“看起来省内存”而提前加指针；先跑
pprof看真实瓶颈，再结合逃逸分析决策
避免常见误用：nil 指针解引用与并发写
指针带来的运行时风险比值类型高得多，两类错误高频且难调试：
- 未判空直接解引用：
if u.Name == "admin" {...}在u为nil时 panicinvalid memory address or nil pointer dereference。所有指针参数都应显式检查：if u == nil { return errors.New("user is nil") } - 多个 goroutine 同时写同一结构体指针字段（如
u.Count++）会引发数据竞争。此时不能靠加指针解决，得用sync.Mutex、atomic或重构为不可变结构体 + 返回新实例 - 切片/Map 字段本身是指针包装类型，即使结构体用值传递，其内部
map或[]int仍共享底层数组——这点常被忽略，误以为“值传参就绝对安全”
真正关键的不是“一律用指针”，而是清楚每个变量的生命周期、所有权边界和并发需求。结构体大小只是起点，逃逸行为、调用上下文、线程安全性才是决定性因素。
