Go 值接收者和指针接收者怎么选：为什么接口实现会不一样

在Go里给方法选值接收者还是指针接收者，最容易踩的坑根本不是语法写错，而是方法集的隐含规则。不少人改代码的时候只把 func (u User) Name() 换成 func (u *User) Name()，结果之前明明能正常赋值给接口的变量突然就编译报错。判断逻辑其实很简单：值接收者的方法，不管是该类型的值实例还是指针实例，一般都能直接调用；而指针接收者的方法，只会归到对应指针类型的方法集里。实际开发的时候，先看这个方法会不会修改当前对象，再看结构体本身的大小，最后再考虑它是不是要实现某个外部定义的接口就行。

最小例子：为什么值不能赋给接口

先看一个极简的复现例子。Counter 有一个 Inc 方法，它要修改内部计数，所以接收者写成指针。这个方法可以通过变量正常调用，但把值类型直接赋给接口时，就会出问题。

type Runner interface {
    Inc()
}

type Counter struct {
    n int
}

func (c *Counter) Inc() {
    c.n++
}

func main() {
    var c Counter
    c.Inc() // 这里可以调用，编译器会帮忙取地址

    var r Runner
    r = c  // 这里不行，Counter 的方法集里没有 Inc
    _ = r
}

很多人在这里卡壳，都是把“能调用方法”和“满足接口”混成了一件事。普通调用时，只要变量可取地址，编译器可以自动帮你把 c.Inc() 当成 (&c).Inc()。但接口赋值看的是类型的方法集，Counter 的方法集不包含指针接收者方法，*Counter 的方法集才包含。

一张表记住方法集差异

方法集可以先按下面这张表记。它不是要求死记硬背，而是解释了为什么有些代码“明明能正常调用”，却不能直接塞进接口变量里。

回到上面的 Counter，如果接口要求 Inc，正确赋值方式是把指针放进去：

var c Counter
var r Runner = &c
r.Inc()

选择规则：先看会不会修改对象

接收者怎么选，第一条先看方法会不会修改对象本身。像计数器累加、缓存写入、状态切换、连接池统计这类方法，都应该用指针接收者。否则方法里修改的只是对象的副本，调用方看到的原对象不会产生任何变化。

type Cart struct {
    Total int
}

func (c Cart) AddWrong(price int) {
    c.Total += price
}

func (c *Cart) Add(price int) {
    c.Total += price
}

AddWrong 看起来会加总价，但它改的是副本；Add 才会修改原对象。这里不要靠命名去猜，直接看接收者是不是指针，才是稳定准确的判断方式。

结构体大、带锁或带缓冲区时也优先指针

即使方法不修改字段，大结构体也不适合频繁按值复制。比如结构体里有较大的数组、缓存片段、批量统计字段，值接收者每次调用都会复制一份，读代码的时候看起来像普通轻量调用，实际运行的复制成本可能超出预期。

带锁的结构体更要谨慎。复制带锁对象通常不会是你预期的行为，后续排查并发相关问题会额外增加很多复杂度。类似这种类型，接收者最好统一写指针：

type SafeBox struct {
    mu   sync.Mutex
    data map[string]string
}

func (b *SafeBox) Get(key string) string {
    b.mu.Lock()
    defer b.mu.Unlock()
    return b.data[key]
}

这里即使 Get 只是读数据，也不建议写成值接收者，因为复制锁和 map 头部都不符合调用者的常规直觉。

什么时候值接收者更合适

值接收者不是不能用。小型、语义上本身就属于值的类型，用值接收者反而更自然。例如坐标、金额、颜色、时间范围、不可变配置片段，这些类型的方法通常只做计算或格式化，不需要修改原对象。

type Point struct {
    X, Y int
}

func (p Point) String() string {
    return fmt.Sprintf("(%d,%d)", p.X, p.Y)
}

这种类型用值接收者还有一个好处：Point 和 *Point 都能调用 String，也更容易满足只要求读取方法的接口。

相关问题

同一个类型能不能混用值接收者和指针接收者？

语法上允许，但不推荐随意混用。少量只读格式化方法用值接收者还可以接受；如果类型大部分方法都需要指针，最好统一用指针，减少后续接口兼容的判断成本。

为什么 c.Inc() 能调用，var r Runner = c 却不行？

普通方法调用可以在变量可取地址时自动取地址；接口赋值看的是类型原生的方法集，不会把值类型自动当成指针类型放进去。

指针接收者一定更快吗？

不一定。小结构体按值复制成本很低，值接收者的语义反而更清晰。是否更快要看对象大小、调用频率和逃逸情况，不能只按“指针一定省内存”来判断。

接口里要求的方法应该写成值接收者还是指针接收者？

接口本身不写接收者，它只声明方法名和参数。真正影响接口实现的是具体类型的方法接收者：方法写在值上，值和指针更容易满足接口；方法写在指针上，通常只有指针能满足接口。