17370845950

指针接收者允许方法修改原始结构体字段，值接收者仅操作副本；指针接收者是接口实现和大结构体高效调用的必要选择，方法集差异决定接口赋值合法性。

指针接收者能让方法

修改原始结构体字段

值接收者传入的是结构体副本，所有字段修改都只作用于副本，调用方的原始变量完全不受影响；指针接收者传入的是地址，方法内通过 p.Field = value 直接改写原始内存里的数据。

• 必须用指针接收者才能实现状态变更，比如 func (u *User) SetEmail(email string)
• 值接收者方法（如 func (u User) Name() string）天然适合只读计算，语义更清晰
• Go 允许你用 user.SetEmail("a@b.c") 这种写法，即使 user 是值变量 —— 编译器自动转成 (&user).SetEmail(...)，但前提是 user 必须是可寻址的（不能是字面量 User{}）

接口赋值失败？大概率是忘了取地址

如果一个类型只用指针接收者实现了某个接口，那么只有 *T 能赋给该接口变量，T 会直接编译报错：cannot use t (type T) as type Interface in assignment。

• 错误示例：

  type Speaker interface { Speak() }
  type Dog struct{}
  func (d *Dog) Speak() { fmt.Println("Woof!") }
  
  var d Dog
  var s Speaker = d // ❌ 编译失败

• 正确写法：s = &d 或构造时就用指针：s = &Dog{}
• 混用值/指针接收者极易导致接口实现不一致：只要有一个方法用了指针接收者，建议全类型方法统一用指针，避免部分能赋值、部分不能的混乱

为什么大结构体一定要用指针接收者？

不是“一定”，而是“不这样做会付出明显代价”。假设结构体有 20 个字段（约 160 字节），每次调用值接收者方法都会复制整块内存 —— 对高频方法（如 String()、MarshalJSON()）就是隐性性能瓶颈。

• 指针接收者固定只传 8 字节（64 位系统），零拷贝
• 标准库中几乎所有结构体方法（sync.Mutex、bytes.Buffer、http.Request）都用指针接收者，既是惯例，也是实践验证过的合理选择
• 小结构体（如 type ID int、type Point struct{X,Y int}）用值接收者反而更轻量，无须间接寻址

方法集（method set）决定接口能否被满足

Go 中「类型 T 的方法集」和「类型 *T 的方法集」是两个不同的集合。这是理解接口赋值行为的底层依据，不是语法糖，是硬性规则。

• T 的方法集：只包含值接收者方法（func (T) M()）
• *T 的方法集：包含值接收者 + 指针接收者方法（func (T) M() 和 func (*T) M()）
• 所以 *T 总能赋给接口，而 T 只能在所有接口方法都是值接收者时才可赋值
• 这个规则在嵌入结构体、泛型约束、类型断言时也会浮现，是容易被忽略但影响深远的一环

指针接收者不是语法装饰，它绑定着内存所有权、接口兼容性和运行时调度路径——哪怕你没显式写 &，Go 也在背后严格按这套规则做检查和分发。