17370845950

接口赋值成败取决于方法接收者类型：值接收者时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 指针指向什么：

• 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) 会输出 ，但不会 panic，因为类型信息还在

底层结构上，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 的地址

关键点在于：接口从不“知道”自己装的是指针还是值——它只忠实地保存你给它的那个东西的类型和地址。所谓“指针与接口的关系”，其实是你写赋值语句时，就已经决定了后续一切行为边界。