结构体方法需修改字段时必须用指针接收者，因值接收者操作副本；返回大结构体或需表达“可空”语义时优先用指针；参数传递仅当需修改或避免拷贝开销才用指针；小结构体值传更安全高效。
结构体方法需要修改字段时，必须用指针接收者
Go 中值接收者操作的是结构体副本，改了也不会影响原始变量。比如 func (u User) SetName(name string) 无论怎么赋值，调用方的 u 名字都不会变；而 func (u *User) SetName(name string) 才能真正写回原结构体。
- 只要方法内部有类似
u.Age = 25这样的赋值，接收者就必须是指针类型 - 即使结构体很小（比如只有两个字段），只要需修改，就别犹豫用
*User - 混用值/指针接收者容易导致方法集不一致：如果某个接口要求
*User实现方法，但你只给User写了值接收者，编译会报错
返回大结构体或含大字段时，优先返回指针
函数返回值会触发完整拷贝。一个含 1MB 切片的结构体，用值返回就是一次 1MB 内存复制；用指针返回只传 8 字节地址——性能差距显著。
- 典型场景：
bytes.NewBuffer、sync.Pool.Get返回的都是指针，因为底层可能持有大缓冲区或缓存对象 - 判断“是否算大”：结构体字段总大小 > 64 字节，或包含
[]byte、map[string]interface{}、嵌套结构体等，就值得考虑指针 - Go 编译器会自动做逃逸分析，
return &MyStruct{...}是安全的，不用担心局部变量地址失效
需要表达“可空”语义时，返回结构体指针比多加布尔返回值更简洁
比如查找用户：用 func FindUser(id int) *User，调用方直接 if u := FindUser(123); u != nil { ... }；若用值返回，就得写成 func FindUser(id int) (User, bool)，调用侧要多解包、易漏判。
- 适合所有“可能不存在”的场景：配置加载、数据库查询、缓存获取
- 注意：返回
nil指针本身没问题，但后续使用前必须检查，否则u.Name会 panic - 不要对小结构体（如
type Status struct{ Code int; Msg string }）滥用此模式——值返回更轻量、更直观
参数传递中，仅当需修改原值或避免拷贝开销时才传指针
传 *User 不是为了“看起来高级”，而是有明确目的：要么改它，要么省拷贝。否则传值更安全、更符合 Go 的默认习惯。
立即学习“go语言免费学习笔记（深入）”；
- 基础类型（
int、string、bool）永远用值传递，指针反而增加间接寻址开销 - 小结构体（≤ 3 字段，且无大 slice/map）也建议值传——现代 CPU 对 24 字节以内的拷贝极快，可读性更重要
- 并发场景下，共享指针必须配同步机制：
sync.Mutex或atomic，否则多个 goroutine 同时写u.Age会数据竞争
最容易被忽略的一点是：指针不是性能银弹。很多开发者一看到“结构体”就本能加 *，结果让本该只读的小配置对象变得可变、难以测试、调用方不敢放心复用。真正该问的不是“能不能用指针”，而是“这个变量是否需要被多个地方共同修改？它的大小是否真的值得绕过拷贝？”——答案清楚了，指针用不用，自然就定了。
