Go中允许但不推荐使用指向接口的指针，因接口本身具备引用语义，包含动态类型和值，直接传递接口即可实现所需行为，无需额外取地址；虽然语法上可定义*interface{}并传参，如在反射或Unmarshal场景中需传变量地址以修改其内容，但这并非设计意图，且易引发误解、降低可读性、增加nil判断复杂度；应优先使用接口值而非指针，保持代码清晰安全。
在Go语言中，接口（interface）是一种类型，它定义了一组方法签名。任何实现了这些方法的类型都自动满足该接口。关于“指向接口的指针”是否可以使用，答案是：语法上允许，但通常不推荐，且容易引发误解。
接口本身就是引用语义
Go中的接口类型本身已经具备引用特性。一个接口变量内部包含两部分：动态类型和动态值。这意味着你不需要通过指针来传递接口以实现修改或避免拷贝。
例如：
type Speaker interface {
Speak()
}
type Dog struct{}
func (d Dog) Speak() {
fmt.Println("Woof")
}
func main() {
var s Speaker = Dog{}
process(s) // 直接传接口，无需取地址
}
func process(sp Speaker) {
sp.Speak()
}
这里直接传值即可，不会影响行为正确性。
立即学习“go语言免费学习笔记（深入）”；
可以定义指向接口的指针，但意义有限
虽然你可以写 *Speaker，即指向接口类型的指针，但这并不等同于指向实现了接口的底层类型的指针。
常见误区示例：
func modifySpeaker(sp *Speaker) {
*sp = Cat{} // 可以赋值新的实现
}
var s Speaker = Dog{}
modifySpeaker(&s) // 传接口变量的地址
这在技术上是可行的——你可以取一个接口变量的地址，并通过指针修改它指向的内容。但这种做法很少必要，因为直接传接口值更清晰安全。
使用指针到接口的问题
- 难以理解：*interface{} 容易与 interface{} 混淆，造成代码可读性下降。
- 无法访问底层类型方法：即使你有一个 *Speaker，也不能直接调用其底层具体类型的额外方法，仍需类型断言。
- nil判断复杂化：你需要同时检查指针是否为nil，以及接口是否为nil，逻辑变复杂。
- 反模式：标准库和主流项目几乎从不使用 *interface{} 作为参数类型。
什么时候可能见到 *interface{}
极少数情况出现在需要反射的场景，比如：
var v interface{}
json.Unmarshal(data, &v) // 这里传的是 &v，因为Unmarshal需要修改v
但这不是“使用指向接口的指针”的设计选择，而是函数要求传入一个可被设置的地址。此时 v 是变量，&v 是它的地址，无论其类型是 interface{} 还是其他。
基本上就这些。Go中可以直接使用接口值，避免使用指向接口的指针。除非你明确知道自己在做什么，否则不要将接口类型作为指针传递。保持简单：用接口值，不用*interface。
