Go中接口能否被调用取决于方法集是否匹配：值接收者方法仅属于类型T的方法集，指针接收者方法属于*T的方法集，故Dog{}不能赋值给含指针接收者方法的接口，而&Dog{}可以。
Go 中接口能否被调用，不取决于你“想不想用”，而取决于方法集是否匹配——值接收者和指针接收者生成的方法集不同，直接决定类型能否赋值给接口变量。
值接收者 vs 指针接收者：方法集差异决定接口满足性
一个类型是否满足某个接口，由其**方法集**（method set）决定，而非结构体字段或命名。Go 规定：
- 类型
T的方法集只包含 **值接收者** 方法 - 类型
*T的方法集包含 **值接收者 + 指针接收者** 方法
这意味着：Dog{} 能赋给只有 Speak()（值接收者）的接口，但无法赋给同时要求 Move()（指针接收者）的接口；而 &Dog{} 可以满足两者。
常见错误现象：cannot use d (type Dog) as type Mover in assignment: Dog does not implement Mover (Move method has pointer receiver)
立即学习“go语言免费学习笔记（深入）”；
实操建议：
- 统一使用指针接收者定义方法，避免因调用方传值/传指针不一致导致接口不满足
- 若必须混用，用编译期断言提前暴露问题：
var _ Speaker = Dog{}和var _ Mover = (*Dog)(nil)分别校验 - 不要在测试中临时改接收者类型来“凑过编译”，那只是掩盖了设计不一致
接口变量赋值时的隐式取地址行为
当你写 var w io.Writer = os.Stdout，看似是把值赋过去，其实 Go 在底层对 os.Stdout（类型为 *os.File）做了隐式取地址——因为 io.Writer 要求的 Write 方法是用指针接收者实现的。
但这个隐式行为**仅适用于地址可取的变量**。比如：
-
var w io.Writer = bytes.Buffer{}会失败：因为bytes.Buffer.Write是指针接收者，而字面量bytes.Buffer{}是不可寻址的临时值 - 正确写法是
var w io.Writer = &bytes.Buffer{}或先声明再取址：b := bytes.Buffer{}; w := io.Writer(&b)
容易踩的坑：在单元测试中直接传结构体字面量给依赖接口的函数，结果 panic 报 nil pointer dereference，根源常是忘了取址。
组合接口时方法签名冲突的硬性限制
接口组合不是“合并功能”，而是**摊平所有嵌入接口的方法签名后做一致性校验**。一旦两个嵌入接口含同名方法但签名不同，编译直接报错。
例如：
type Reader interface {
Read(p []byte) (n int, err error)
}
type Closer interface {
Close() error
}
type BadCombo interface {
Reader
Closer
// 假如这里额外加一个 Close() bool —— 编译失败：duplicate method Close
}
更隐蔽的问题：
-
io.ReadCloser同时嵌入io.Reader和io.Closer，两者都定义了Close() error，完全一致 → 合法 - 若你自定义
MyReader也带Close() error，再组合时仍合法；但只要有一个是Close() bool，整个接口就无效 - 这种冲突不会在实现端暴露，而是在接口定义处就卡死，所以组合前务必确认各接口方法语义与签名严格一致
真正难处理的不是语法报错，而是那些“看起来能跑、运行时才出问题”的场景：比如指针接收者方法在 nil 接口值上调用 panic，或者组合接口里 Close 行为实际是重置缓冲区而非释放资源——方法签名对了，语义却没对齐。这类问题没法靠编译器拦住，得靠命名约束和文档约定。
