17370845950

结构体方法需修改字段时必须用指针接收者，因值接收者操作副本；返回大结构体或需表达“可空”语义时优先用指针；参数传递仅当需修改或避免拷贝开销才用指针；小结构体值传更安全高效。

结构体方法需要修改字段时，必须用指针接收者

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 的默认习惯。

• 基础类型（int、string、bool）永远用值传递，指针反而增加间接寻址开销
• 小结构体（≤ 3 字段，且无大 slice/map）也建议值传——现代 CPU 对 24 字节以内的拷贝极快，可读性更重要
• 并发场景下，共享指针必须配同步

  

  机制：sync.Mutex 或 atomic，否则多个 goroutine 同时写 u.Age 会数据竞争

最容易被忽略的一点是：指针不是性能银弹。很多开发者一看到“结构体”就本能加 *，结果让本该只读的小配置对象变得可变、难以测试、调用方不敢放心复用。真正该问的不是“能不能用指针”，而是“这个变量是否需要被多个地方共同修改？它的大小是否真的值得绕过拷贝？”——答案清楚了，指针用不用，自然就定了。