如何理解Golang中接口参数与指针传递_Golang接口调用机制解析_技术教程

接口赋值能否成功取决于方法集：若接口方法用指针接收者实现，则只能传指针；值接收者则值和指针均可。传值修改不影响原数据，传指针可修改原数据；大结构体应优先用指针避免拷贝开销。

接口赋值时，传值还是传指针，直接决定能否满足接口

Go 接口本身不存储“值”或“指针”，它存储的是**具体类型的值（或其地址）+ 类型信息**。但能否把一个变量赋给某个接口，取决于该变量的类型是否实现了接口的所有方法——而这又由方法集（method set）严格控制。

类型 T 的方法集只包含接收者为 T 的方法（值接收者）
类型 *T 的方法集包含接收者为 T 和 *T 的所有方法（值 + 指针接收者）
如果接口中定义的方法是用 *T 接收者实现的，那么只有 *T 可以赋值给该接口；T 会编译报错：cannot use t (type T) as type MyInterface in assignment: T does not i mplement MyInterface

type Speaker interface {
    Speak()
}

type Person struct {
    Name string
}

func (p Person) Speak() {        // 值接收者 → T 实现了 Speaker
    fmt.Println(p.Name)
}

func (p *Person) Shout() {       // 指针接收者 → 只有 *Person 有 Shout
    fmt.Println("HEY", p.Name)
}

// ✅ OK：值接收者，Person 和 *Person 都能赋给 Speaker
var s1 Speaker = Person{"Alice"}
var s2 Speaker = &Person{"Bob"}

// ❌ 编译错误：Person 没有实现 Shouter（假设 Shouter 要求 *Person.Shout）
type Shouter interface { Shout() }
var sh Shouter = Person{"Charlie"} // error

函数参数是接口时，传值 vs 传指针影响的是「底层数据是否可修改」

接口变量内部有两个字（16 字节）：一个存类型头（type info），一个存数据（data word）。当你把 Person{} 或 &Person{} 赋给接口，接口里存的就是那个值的副本或地址副本——所以「能不能改原始数据」，取决于你当初塞进去的是值还是指针。

传 Person{} → 接口内保存的是结构体副本 → 方法内修改字段不会影响原变量
传 &Person{} → 接口内保存的是指针副本 → 方法内通过 p.Name = "New" 可修改原始结构体
注意：指针副本 ≠ 引用传递，只是地址的拷贝，和 func f(p *int) 本质一致

func greet(s Speaker) {
    if p, ok := s.(Person); ok {
        p.Name = "Modified" // ✅ 编译通过，但只改副本，不影响外面
    }
    if pp, ok := s.(*Person); ok {
        pp.Name = "AlsoModified" // ✅ 改的是原始结构体（前提是 s 是 *Person）
    }
}

大结构体实现接口时，不传指针会悄悄拖慢性能

如果你定义了一个 2KB 的结构体，并让它实现某个接口，然后在高频调用中反复以值方式传给接口参数（比如日志、中间件、mock 测试等场景），每次调用都会触发一次 2KB 内存拷贝——这不是 GC 问题，是纯 CPU 和内存带宽浪费。

结构体字段总大小 ≤ 16 字节（如两个 int64）：值传递通常更快，且更安全
结构体含 slice/map/chan/func 或字段总大小 > 64 字节：强烈建议统一用 *T 实现接口并传指针
逃逸分析（go build -gcflags="-m"）会告诉你变量是否逃逸到堆，但别依赖它做设计决策；语义优先

最容易被忽略的坑：同一个类型混用值/指针接收器会导致接口实现不一致

这是线上静默 bug 的高发区。比如你先写了 func (u User) Save()，后来加了个 func (u *User) Update()，再定义一个需要这两个方法的接口 SaverUpdater ——那么 User{} 能满足 Save()，但不满足 Update()；而 &User{} 全都满足。结果就是：