在Go语言的日常开发中，我们经常写出这样的代码：定义一个接口，再定义一个结构体，然后用结构体或者结构体指针去实现这个接口。但如果反过来问：能不能创建一个指向接口的指针，比如*io.Writer或者*interface{}？这个问题看似简单，背后其实牵扯到Go类型系统对接口的底层设计。本文将围绕这个问题展开讨论，先给出结论，再从原理层面解释为什么，最后给出实际开发中的使用建议。
结论先行：语法上可以，但几乎没有意义
首先要明确一点：在Go语言中，声明一个指向接口的指针在语法层面是完全合法的。你可以写出var p *io.Writer这样的代码，编译器不会报错。但如果你的本意是像操作结构体指针那样，通过指针来修改接口或者提升性能，那就完全想偏了。
Go编译器甚至会对一种常见误用直接给出警告。当你试图对一个接口变量取地址时，比如写出下面这段代码：
package main
import "fmt"
func main() {
var w interface{ Write(p []byte) (int, error) }
p := &w // 编译器提示：cannot take address？其实能编译，但go vet会警告
fmt.Println(p)
}
这段代码虽然能通过编译，但运行go vet时会得到明确的提示：对接口变量取地址是不必要的。原因是接口值本身在Go中就已经是引用语义的载体，它内部包含了足够的信息，再包一层指针除了增加一次间接寻址之外，得不到任何好处。
总结成一句话：接口指针在Go中合法但无用，标准库和社区惯例从不这样写。如果你在代码里看到*interface{}，几乎可以断定这是一个从C语言或者C++迁移过来的开发者写出的习惯性代码，需要重构。
理解接口值的双字结构是关键
要彻底理解为什么接口指针没有意义，必须先搞清楚接口值在Go运行时的内部表示。Go语言规范并没有强制规定接口的内存布局，但官方运行时的实现中，一个接口值由两个机器字组成：第一个字指向一个ITab（或者空接口情况下指向类型信息），第二个字指向实际的动态值或者直接内联存储值。
换句话说，当你写下var w io.Writer = os.Stdout时，变量w里面存的并不是os.Stdout的一份拷贝，而是一个描述了动态类型信息和一个指向具体值的引用。把这个结构体传给函数时，传递的是这两个字的副本，看起来像是值传递，但由于第二个字本身就是指针，所以接口内部持有的数据并不会被复制。
package main
import (
"fmt"
"io"
)
func main() {
var w io.Writer = &bytesBufferProxy{}
// 接口值只占两个机器字
fmt.Printf("大小: %d 字节\n", sizeOfInterface(w))
}
type bytesBufferProxy struct{}
func (b *bytesBufferProxy) Write(p []byte) (int, error) {
return len(p), nil
}
func sizeOfInterface(_ io.Writer) int {
return 16 // 64位平台上两个机器字
}
正因为接口值内部已经持有对动态值的引用，对接口本身再取指针，得到的是一个指向双字结构的指针。这个操作既不能改变接口的方法集，也不能减少数据拷贝，纯粹是画蛇添足。这也是Go 1.x系列编译器在遇到&someInterface时会给出警告的根本原因。
方法集规则：值接收者与指针接收者的选择
讨论接口与指针的关系时，绕不开Go方法集规则，这也是很多困惑的真正来源。规则可以概括为两句话：类型T的方法集包含所有以T为接收者的方法；类型*T的方法集则同时包含以T和*T为接收者的方法。这直接决定了一个值或者指针能否赋值给某个接口变量。
package main
import "fmt"
type Speaker interface {
Speak() string
}
type Cat struct {
Name string
}
// 值接收者
func (c Cat) Speak() string {
return c.Name + ": 喵"
}
// 指针接收者版本，用于对比
type Dog struct {
Name string
}
func (d *Dog) Speak() string {
return d.Name + ": 汪"
}
func main() {
var s Speaker
s = Cat{Name: "咪咪"} // 合法：Cat实现了Speak
fmt.Println(s.Speak())
s = &Dog{Name: "旺财"} // 合法：*Dog实现了Speak
fmt.Println(s.Speak())
// s = Dog{Name: "旺财"} // 编译错误：Dog没有实现Speak
}
注意上面被注释掉的那行：如果把Dog的值直接赋给接口变量，编译器会报错，提示Dog没有实现Speaker接口。原因在于Speak方法的接收者是*Dog，而Dog的方法集中不包含这个方法。Go不允许自动获取接口内部值的地址，因为它无法保证这个值是可寻址的。
由此可以得出实践建议：如果你的类型中任何一个方法使用了指针接收者，那么保持一致性，所有方法都用指针接收者，并且在赋值给接口时始终传递指针。反过来，如果类型很小、不可变、没有修改内部状态的需求，用值接收者可以让值和指针都满足接口，灵活性更高。无论选择哪种，指向结构体的指针实现接口和指向接口本身的指针是完全不同的两件事，前者是Go的常规操作，后者则是误区。
常见误用场景与规避方法
第一种典型误用出现在泛型参数和函数签名中。有些开发者会写出*interface{}或者*any作为参数类型，希望通过指针让函数能够修改传入的值。这种写法往往源于对Go语义的误解。看下面的例子：
package main
import "fmt"
// 错误示范：对接口取指针毫无必要
func badSet(dst *interface{}, val int) {
*dst = val
}
// 正确做法：直接传递接口值
func goodSet(dst *interface{}, val int) {
*dst = val // 虽然能工作，但更好的设计是用具体类型或泛型
}
func main() {
var box interface{}
badSet(&box, 42)
fmt.Println(box)
}
上面这个例子虽然能运行，但它暴露了设计上的坏味道：用interface{}承载任意值再通过指针修改，类型安全性为零。现代Go提供了更好的工具——泛型。用类型参数替代空接口，既保留了灵活性，又让编译器帮你做类型检查。
第二种误用是尝试通过*SomeInterface类型来规避接口未实现的编译错误，或者把接口指针放进map、slice里当作一种退化用法。遇到这类需求时，正确的思路是检查方法集规则，确认接收者类型是否匹配，而不是绕弯子制造接口指针。如果你需要修改结构体的状态，就传递结构体指针并让指针实现接口；如果你需要多态行为，就传递接口值。Go的类型系统设计哲学是让每一种用法只有一条正路，理解了这条正路，那些奇怪的组合自然就不会再出现在你的代码里。
最后补充一点：在极少数场景下，比如需要满足某个老旧第三方库的函数签名，确实可能被迫写出接口指针，此时加上清晰的注释说明原因即可，但不要把它当成通用模式传播给团队。
Golang接口指针Go类型系统接口实现修改时间：2026-09-06 17:12:38