用 Go interface{} 等于什么也没说

大家好，我是煎鱼。,如果说在 Go 里要有一句与 interface{} 相关，你会想到什么？是万物皆要定义 interface，否则没法抽象？,Go 谚语中认可的是："interface{} says nothing"，也就是 interface{} 什么也没说。这指的又什么，太黑话了吧...,今天就煎鱼和大家一起学习。,interface{} 的第一种用法，那就是变量的数据类型声明。结合其它语言来看，一共有如下几种形式：,Go 在 1.18 后，也支持了 any 关键字的声明方法，是类似 interface{} 的作用，各路语言都趋同了。,在实际编程中频繁的用接口（interface{}）类型作为变量的类型有没有问题呢？,明确的声明,当我们在阅读 Go 代码时。如果文档、命名、、参数（含类型）是清晰的，可靠的。我们大概率会直接调用，明确的类型会更让我们有 ”安全感“，知道要传什么值。,如下函数签名：,当然知道调用 Eat 函数要传 string 类型了，不是传什么 int 类型。,未知的声明,如果一个函数的参数的类型是 interface{}，我们就会进函数内看其具体的实现，以此寻求确定性。,如下函数签名：,请问变量 v 到底传什么，传 int 类型，还是 string 类型，又或是都可以？,正如谚语中所说，定义了 interface{}，是什么都没说，显然是 “不大好的味道”，这样的代码无法自描述。程序员得翻代码或文档（文档还不一定更新的及时）。,注：在公司真见到这种场景，该位同学猜不透，大呼绝绝子，翻代码去了。,小接口优于大接口,在 Go 的标准库中，package io 的 io.Reader 和 io.Writer 接口是官方认可的教科书式案例，小而美的接口是编写强大而灵活的 Go 代码的关键。,io.Reader：,io.Writer：,小接口与大接口相比，用户认知的心智和实现成本较低。,从现实情况来讲，当一个 Go 代码库中拥有 6 个，甚至更多的大型接口往往只有两种实现，那就是唯一的具体实现和一个用于测试的模拟实现。,另外从历史的角度来看， io.Reader 和 io.Writer 接口并不是前期设计的，它们是后来发现的。Network、File 和其他字节处理类型需要共享类似的实现，才诞生的 io.Reader 和 io.Writer 。,“最佳实践” 都是实践、探索、演变出来的。,今天我们对 Go 谚语中的："interface{} says nothing" 进行了大致的了解，内容不多，核心的官方建议在于：,当一个接口定义拥有 6 个或更多的接口方法时，它非常的鸡肋，一般只有自身的具体实现和测试实现。,建议多采取小接口的方式，认知和实现成本低。官方认可的最佳实践是 io.Reader 和 io.Writer 接口，太大的接口并没有太多的好处。,你觉得这个 Go 谚语靠谱吗？你是否有大接口的使用经验？,Go1.18 有了泛型后，泛型具有的相对定义，是否可以解决这个问题？