接口赋值成败取决于方法接收者类型：值接收者时T和T均实现，指针接收者时仅T实现；nil指针赋给接口不为nil，因接口含类型信息和nil地址。
接口不是引用类型，但它内部存指针；赋值时复制的是“类型+值”，而这个值可以是指针，也可以是值本身。
为什么 var s speaker = p 有时编译失败？看方法接收者类型
接口能否被某个变量满足，不取决于你“想不想传指针”，而取决于该变量的类型是否真实现了接口所有方法。go 的方法集规则直接决定成败：
- 如果方法定义为
func (t T) Method()（值接收者），那么T和*T都实现该接口 - 如果方法定义为
func (t *T) Method()（指针接收者），只有*T实现，T不实现 - Go 不允许对值类型隐式取址两次，所以
T{}无法自动转成*T再去调用指针方法
常见错误现象：cannot use p (type Person) as type Speaker in assignment: Person does not implement Speaker —— 就是因为 Speak() 是指针接收者，但你传了 Person{} 而非 &Person{}。
给接口赋值时，person 和 &person 到底差在哪？
差别不在接口变量本身（它始终是值类型，大小固定为两个机器字），而在它内部的 data 指针指向什么：
立即学习“go语言免费学习笔记（深入）”；
-
s := Speaker(person)→data指向一个Person副本，方法内修改字段不影响原变量 -
s := Speaker(&person)→data指向&person，方法内可修改原始person字段 - 大结构体（如含切片、map 的 Struct）用值赋值会触发完整拷贝，开销明显；用指针则只拷贝一个地址（8 字节）
实操建议：除非明确需要隔离副本或方法逻辑纯读取，否则结构体方法优先用指针接收者，并统一用 &v 赋值给接口。
为什么 var p *Dog = nil; var s Speaker = p 后 s == nil 是 false？
这是最常踩的坑：nil 指针赋给接口 ≠ 接口为 nil。因为接口变量 s 内部仍包含完整的类型信息（*Dog）和一个值（nil 地址），它是一个“非空的接口值”：
-
s == nil判断的是整个接口是否为零值（即type == nil && data == nil），而这里type是*Dog，不为 nil - 正确判空方式是先断言再检查：
if dog, ok := s.(*Dog); ok && dog == nil { ... } - 同理，
fmt.Println(s)会输出
底层结构上，iface 和 eface 怎么区分指针与值？
无论你传的是 int、*os.File 还是 []byte，接口底层都只做两件事：记下类型、存好数据位置：
- 非空接口（如
io.Reader）用iface结构：含tab *itab（方法表）和data unsafe.pointer（指向值或指针） - 空接口（
Interface{}）用eface：只有_type *_type和data unsafe.Pointer，没方法表 -
data指针的语义完全由赋值时的右值决定：传val就指向栈/堆上的副本；传&val就直接指向val的地址
关键点在于：接口从不“知道”自己装的是指针还是值——它只忠实地保存你给它的那个东西的类型和地址。所谓“指针与接口的关系”，其实是你写赋值语句时，就已经决定了后续一切行为边界。