大家好，我是建宇。如果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接口是官方认可的教科书案例。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接口。你觉得这些建议靠谱吗？你有使用大接口的经验吗？Go1.18有了泛型之后，泛型的相对定义能解决这个问题吗？文章持续更新中。可以微信搜索【脑补炸鱼】阅读。本文已收录在GitHubgithub.com/eddycjy/blog中。学习Go语言可以看Go学习地图和路线。欢迎星星提醒。Go书系列Go语言入门系列：初探Go项目实战Go语言编程之旅：深入使用Go进行项目Go语言设计哲学：理解Go的Why和设计思维把Go代码变成意大利面条？Go程序说nil不是nil真是太疯狂了......
