接口是Go语言中最容易被误解的特性之一。不少人在写代码时都遇到过这样的困惑：定义了一个接口类型的参数，传结构体值进去编译器报错，改成传指针就通过了；或者接口变量明明看起来是nil，用等号判断却返回false。这些问题的根源都藏在一个地方——Go的接口在底层究竟是怎么存储数据的。本文从接口的内存结构入手，逐步拆解值与指针在接口传递中的行为差异，帮你把这块知识彻底理顺。
接口的底层结构：iface与eface
Go的接口变量并不是直接存储你赋给它的值，而是用一个两字的结构体来承载信息。对于空接口interface{}（新版本可写作any），编译器使用eface结构，包含两个字段：一个指向类型信息的指针_type，一个指向数据本身的指针data。对于非空接口，则使用iface结构，把类型字段换成了itab，其中不仅包含动态类型，还包含该类型实现接口的全部方法地址。
这个设计决定了两件关键的事。第一，无论你往接口里塞的是值还是指针，接口变量本身始终是两个字长，赋值和传参时复制的只是这两个字。第二，当你把一个具体的值装进接口时，Go会把值复制一份到堆上（如果值本身一个字放不下），接口里的data指针指向这份副本。这就是为什么通过接口调用方法时修改字段，往往不会影响原始变量——你改的是副本。
可以用一段简单的代码观察这个行为：
package main
import "fmt"
type Counter struct {
n int
}
func main() {
var i interface{} = Counter{n: 10}
c := i.(Counter)
c.n = 99
fmt.Println(i.(Counter).n) // 输出 10，接口里存的还是原副本
}
类型断言取出来的又是一份新的拷贝，所以改动c.n对接口内部毫无影响。理解了“接口装箱即复制”，后面很多现象都能解释通了。
值接收者与指针接收者的方法集规则
一个类型能不能赋值给某个接口，取决于它的方法集是否覆盖了接口声明的全部方法。而方法集的判定有一条容易忽略的规则：如果方法用值接收者func (t T) M()定义，那么T和*T的方法集里都有它；如果用指针接收者func (t *T) M()定义，那么只有*T拥有这个方法。
这背后的原因和接口装箱的复制语义直接相关。指针接收者的方法可能会修改接收者指向的数据，如果允许把一个普通的T值装箱进接口再通过接口调用指针方法，实际被修改的只是装箱时复制出来的那份副本，调用方完全感知不到变化，这会造成语义混乱。同时，并非所有值都能取地址——比如 map 中的元素、函数返回的临时值，编译器无法保证取地址操作合法。所以Go干脆规定：只有指针类型才被认为拥有指针接收者的方法。
package main
import "fmt"
type Animal interface {
Speak()
}
type Dog struct {
Name string
}
// 指针接收者
func (d *Dog) Speak() {
fmt.Println("汪汪，我是", d.Name)
}
func main() {
d := Dog{Name: "旺财"}
// var a Animal = d // 编译错误：Dog 没有实现 Animal
var a Animal = &d // *Dog 实现了 Animal
a.Speak()
}
反过来，如果Speak用的是值接收者，那么var a Animal = d和var a Animal = &d都能编译通过。这也解释了一个常见的工程习惯：当一个类型有任何方法需要修改自身状态时，统一让所有方法都使用指针接收者，保持一致性，避免调用方在传值和传指针之间来回纠结。
还有一个细节值得注意：调用方法时的自动取地址是有限制的。d.Speak()在d是可寻址变量时，编译器会自动改写为(&d).Speak()，所以直接调用没问题。但把d装箱进接口时，编译器不会帮你做这个转换，必须显式写&d。
经典陷阱：nil接口判断为什么失效
理解了iface结构，nil接口问题就一目了然了。一个接口变量等于nil，当且仅当它的类型字段和数据字段都是空的。当你把一个nil指针装箱进接口时，类型字段会被填上*T，数据字段为空指针，此时接口整体不等于nil。
package main
import "fmt"
type MyError struct{}
func (e *MyError) Error() string { return "出错了" }
func doWork(fail bool) error {
var e *MyError
if fail {
e = &MyError{}
}
return e // 即使 fail 为 false，返回的 error 也不等于 nil
}
func main() {
err := doWork(false)
fmt.Println(err == nil) // false！
fmt.Println(err) // <nil>
}
doWork返回的类型是error接口，把e装箱时，即使e本身是nil指针，接口的类型字段仍然是*MyError，所以err == nil判断为false，而打印出来却显示nil，这个矛盾现象困扰过非常多的Go开发者。
正确的修复方式有两种：要么让函数在正常路径显式返回nil，要么把返回类型改为具体指针类型*MyError由调用方判断。工程实践中推荐前者，并在代码审查时留意“返回具体类型的nil指针赋给接口变量”这类写法。标准库的reflect.Value.IsNil可以用来检测接口内部的指针是否为空，但更稳妥的做法是从源头避免这种装箱。
接口传参的实战建议
综合上面的原理，日常写代码可以总结出几条实用准则。第一，函数参数定义为接口类型时，你关心的是行为而不是数据形态，此时值和指针的差异由调用方决定，但要确保实现了接口的类型在方法集上不会引起编译歧义。第二，对于体积较大的结构体，装箱值会产生一次完整的复制开销，装箱指针则只复制一个地址，性能敏感路径上优先传指针。第三，如果接口方法需要修改原始数据，必须传指针，否则修改的只是装箱副本。
另外在错误处理和依赖注入场景中，尽量让接口变量保持“要么是真正的nil，要么是有意义的值”这一不变量。返回错误时直接返回nil字面量，而不是经过变量中转的具体类型nil指针；使用工厂函数构造依赖时也遵循同样的原则。这些小习惯能规避掉Go项目中最隐蔽的一类bug。
最后提一个调试技巧：在不确定接口里装的是什么时，可以用fmt.Printf("%T %v\n", i, i)打印动态类型和动态值，或者用反射reflect.TypeOf(i)查看类型信息，能快速定位“接口不是nil却表现为nil”这类问题的根因。把接口的两字结构、方法集规则和装箱复制这三点串起来，Go中绝大多数关于接口参数与指针传递的疑惑都能迎刃而解。