Go interface{} 切片与函数类型陷阱

在学习或使用 Go 的过程中，很多人都会在 interface{} 上踩坑。本文通过两个常见但容易产生误解的问题，解释 为什么 []interface{} 不能接收 []int，以及为什么 func() interface{} 不能接收 func() int，并给出背后的类型与内存模型原因。

---

两个问题

先看两个问题，看看你是否也曾困惑过：

1. func Foo(target []interface{}) 能否传入 []int？
2. func Bar(fn func() interface{}) 能否传入 func() int？

直觉上，这两个问题的答案似乎都应该是「可以」。但在 Go 中，答案都是否定的。

---

interface{} 作为单个参数时

我们先回顾一个大家都熟悉的事实：interface{} 可以接收任意类型的值。

func Foo(a interface{}) {}

Foo(1)
Foo("str")
Foo(1.552)
Foo(nil)
Foo(func() (*Bar, error) {
    return nil, nil
})

这是因为 interface{} 本质上是一个 动态类型容器，它可以在运行时保存任意具体类型的值。

---

当 interface{} 出现在切片中

事情在 interface{} 出现在 切片或数组 中时发生了变化。

func Foo(a []interface{}) {}

Foo([]int{1, 2, 3})      // 编译错误
Foo([]string{"1", "2", "3"}) // 编译错误

这段代码无法通过编译，原因在于：

[]interface{} 和 []int 是两种完全不同的类型，Go 不支持它们之间的隐式转换。

---

根本原因：内存布局不同

interface{} 在底层由两个机器字组成（在 64 位系统上即 16 字节）：

• 一个字：类型信息（type pointer）
• 一个字：数据指针（data pointer）

也就是说：

• 一个 interface{} = 2 个机器字
• 一个 []interface{} 的底层数组 = n * 2 个机器字

而普通切片则不同：

• []int 的底层数组是 n * sizeof(int)
• []string 是 n * sizeof(string)

它们在 内存结构、元素大小、布局方式 上都完全不一致，因此 Go 编译器不可能安全地把 []int 当成 []interface{} 来使用。

如果确实需要这样做，唯一的办法是显式转换：

ints := []int{1, 2, 3}
ifs := make([]interface{}, len(ints))
for i, v := range ints {
    ifs[i] = v
}

---

同样的规则，适用于函数类型

再看第二个问题：

func Bar(fn func() interface{}) {}

func Foo() int { return 42 }

Bar(Foo) // 编译错误

原因和切片完全一致：

• func() interface{} 和 func() int 是 不同的函数类型
• Go 不支持返回值的协变（covariance）

即便 int 可以赋值给 interface{}，也不代表：

func() int  ≠  func() interface{}

函数签名在 Go 中必须 完全一致。

---

设计层面的考虑

Go 选择这种「严格但清晰」的规则，是为了：

• 保证类型安全
• 避免隐藏的内存分配和性能陷阱
• 让接口的成本显式可见

这也是为什么 Go 更鼓励：

• 使用具体类型
• 或者使用 行为接口（method-based interface），而不是 interface{} 容器

---

总结

• interface{} 可以接收任何 单个值
• []interface{} 不能接收 []T
• func() interface{} 不能接收 func() T
• 根本原因是：类型系统 + 内存布局不同

理解这一点，可以避免很多初学 Go 时的「为什么不行」时刻。

---

如果你在设计 API 时发现自己大量使用 []interface{}，那通常是一个值得重新审视设计的信号。