大家好，我是建宇。如果Go中有interface{}相关的一句话，你会想到什么？是不是凡事都要定义一个接口，否则无法抽象？Go谚语中公认的是：“interface{}saysnothing”，即interface{}saysnothing。这是什么意思，太俚语了。。。今天就和大家一起学习一下炸鱼的做法。接口类型不是自描述的interface{}的第一个用法是变量的数据类型声明。结合其他语言，有以下几种形式：leti:any=1;//Typescriptstd::anyi=1;//C++17对象i=1;//Javavariinterface{}=1//GoGo1.18之后，也支持任意关键字的声明方式，类似于interface{}，所有语言都收敛了。在实际编程中频繁使用接口（interface{}）类型作为变量类型有什么问题吗？我们阅读Go代码时的显式声明。如果文档、命名、参数（包括类型）清晰可靠。大概率我们会直接调用，清晰的类型会给我们一种“安全感”，知道传递什么值。函数签名如下：funcEat(vstring){...}当然，我们知道调用Eat函数必须传递string类型，而不是int类型。Unknowndeclaration如果一个函数参数的类型是interface{}，我们会去函数中查看它的具体实现，以寻求确定性。函数签名如下：funcEat(vinterface{}){...}变量v传入什么？是int类型，string类型，还是两者兼而有之？俗话说，定义接口{}什么都不说显然是“难闻的气味”，这样的代码无法描述自己。程序员不得不翻看代码或文档（文档不一定及时更新）。注：在公司看到这种场景，同学想不通。小接口优于大接口在Go的标准库中，io包的io.Reader和io.Writer接口是官方公认的教科书案例。小而漂亮的界面是编写强大而灵活的Go代码的关键。io.Reader:typeReaderinterface{Read(p[]byte)(nint,errerror)}io.Writer:typeWriterinterface{Write(p[]byte)(nint,errerror)}小接口大与界面相比，用户认知的心态和实现成本更低。实际上，当你在Go代码库中有6个或更多大接口时，通常只有两个实现，即唯一的具体实现和用于测试的模拟实现。另外，从历史上看，io.Reader和io.Writer接口不是早期设计的，是后来发现的。网络、文件和其他字节处理类型需要共享一个类似的实现，这导致了io.Reader和io.Writer。“最佳实践”都是经过实践、探索和演进的。小结今天我们对Go谚语有了一个大概的了解：“interface{}saysnothing”。两者都带来了一些麻烦，好像什么也没说。不建议经常使用。小接口大接口：当一个接口定义有6个以上的接口方法时，就很鸡肋了，一般只有自己的具体实现和测试实现。建议多采用小接口方法，认知和实现成本低。官方公认的最佳实践是io.Reader和io.Writer接口，太大的接口并没有多大用处。你认为这句Go谚语是真的吗？您有使用大型界面的经验吗？Go1.18有了泛型之后，泛型的相对定义能解决这个问题吗？
