答案：Go中虽可创建指向接口的指针，但因语义混淆、双重nil风险、性能损耗及方法调用复杂而不推荐；应直接使用接口值传递，仅在需共享接口变量本身时才用指针。

在Go语言中，可以创建指向接口的指针，但这种做法既不常见，也通常不推荐。理解其背后的类型系统机制和实际使用中的限制，有助于写出更清晰、安全的代码。

接口的本质与指针指向接口的语法可行性

Go中的接口是一种抽象类型，它由方法集定义。一个接口变量实际上包含两个指针：一个指向类型信息，另一个指向具体数据。这意味着接口本身已经是一种“间接引用”。

尽管如此，Go语法允许你声明指向接口类型的指针，例如：

var r io.Reader
var pr *io.Reader = &r

这段代码是合法的。你获取了一个接口变量的地址，创建了一个*io.Reader类型的指针。这说明语法上是允许的，编译器不会报错。

Golang Uber Dig

使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等

下载

立即学习“go语言免费学习笔记（深入）”；

为什么不推荐使用指向接口的指针

虽然技术上可行，但在实际开发中应避免使用指向接口的指针，主要原因如下：

• 语义混淆：接口本意是隐藏底层实现细节，而使用接口指针容易让人误解为需要操作某个具体类型的地址，破坏了抽象性。
• 空值判断复杂化：*io.Reader可能为nil，而它指向的接口变量也可能内部为nil，导致双重nil检查，增加出错概率。
• 不必要的间接层：接口本身已是动态调度的间接机制，再加一层指针会降低性能并使代码更难理解。
• 方法调用受限：通过*interface调用方法需先解引用，若处理不当易引发panic。

正确使用接口的建议

为了保持代码简洁和可维护性，应遵循以下实践：

• 直接传递或赋值接口变量，而不是取地址传递。
• 函数参数应声明为接口类型而非指向接口的指针。
• 结构体字段如需多态行为，应使用接口类型，而非*interface{}。
• 只有在极少数需要共享接口变量本身（而非其所含值）时才考虑使用指针，例如多个地方需修改同一个接口变量的绑定目标。

基本上就这些。Go的设计鼓励值语义和清晰的接口边界，滥用指针会违背这一原则。理解接口的运行时结构和指针的语义，能帮助你做出更合理的选择。