Go中方法必须带接收者而函数不能，指针接收者可修改原值、值接收者仅操作副本，接口实现要求接收者类型一致，小结构体值接收者更高效。
方法必须带接收者，函数不能有接收者
Go 里“方法”和“函数”是语法层面严格区分的两类东西：func (r ReceiverType) 这段前置声明就是方法的身份证。没有它，就是普通函数；有了它，编译器立刻识别为绑定到 ReceiverType 的方法。
函数调用直接写 add(a, b) 或 strings.TrimSpace(s)；方法必须通过实例调用，比如 p.GetName()、db.Close()。哪怕 p 是值类型，db 是指针类型，只要它们属于对应接收者类型，就能调——Go 编译器会自动补 & 或解引用，但这只是语法糖，不改变底层语义。
常见错误现象：cannot call pointer method on User{}。这是因为 User{} 是不可寻址的字面量，编译器无法取地址传给指针接收者。修复方式不是改调用，而是改接收者类型，或确保传入的是可寻址变量（如 u := User{}; u.Save()）。
指针接收者能改原值，值接收者只能改副本
这是最常踩坑的点。写 func (u User) SetName(n string)，再怎么 u.Name = n，原 User 实例字段也不会变——你操作的是栈上临时拷贝。而 func (u *User) SetName(n string) 中的 u 指向原始内存，赋值生效。
立即学习“go语言免费学习笔记（深入）”；
使用场景判断依据很实在：
- 需要修改字段（比如
Close()清空连接、Inc()更新计数器）→ 必须指针接收者 - 只读计算（比如
String()、Hash()、Validate()）→ 值接收者更安全，避免意外 nil 解引用 - 结构体含
sync.Mutex、[]byte、map、大数组 → 即使字段少，也建议指针接收者：复制 slice header 或 map header 看似轻量，但背后数据可能巨大
性能影响真实存在：一个含 10 个 string 字段的结构体，按值传递至少拷贝几百字节；指针永远只传 8 字节地址。
接口实现要求接收者类型一致
接口能否被满足，取决于方法集（method set）规则：
-
type T的方法集只包含值接收者方法 -
*T的方法集包含值接收者 + 指针接收者方法
所以如果接口定义了 Save() error，而你只实现了 func (u *User) Save()，那么 User{} 就无法赋值给该接口变量，只有 &User{} 可以。编译报错：User does not implement Saver (Save method has pointer receiver)。
容易忽略的连锁反应：一旦某个方法因需修改状态用了指针接收者，其余方法最好统一用指针接收者。否则会出现“同一个结构体，有的方法能改状态、有的不能”，调用方困惑，接口实现断层，后期加功能还得批量改接收者——破坏性远超初期多敲几个 *。
小结构体用值接收者反而更高效
不是所有情况都该无脑上指针。对 ≤24 字节且不含指针字段的小结构体（比如 type Point struct{ X, Y int }），值接收者更快更安全：
- 复制两个
int比传指针+解引用还轻量，没有 cache miss 风险 - 天然线程安全：方法内修改副本，不影响其他 goroutine 看到的值
- 语义清晰：
func (p Point) Distance(q Point) float64明确表达“计算派生值”，调用方无需担心副作用
反例：哪怕 type Config struct{ Host string; Port int } 看似小，但 Host 是字符串头（24 字节），背后可能指向几 KB 的内存；此时指针接收者更稳妥。
真正关键的不是“结构体有多大”，而是“复制成本是否可接受 + 是否需要修改原值 + 是否要实现接口”。三者缺一不可，漏掉任何一个，都可能让代码在后期悄悄出问题。
