其实主要分为3大类问题：

1.接口与结构体的类型匹配问题(早就理解了，不过回头看来，也是一种赋值操作)
2.函数数据类型与与其对应的函数变量之间的类型匹配(其实本质是赋值操作)
3.被type的某种类型与这种类型自身变量之间的类型匹配问题(原始类型变量赋值给type后的新类型（别名&容器）)

罗列出来后思路立刻变得清晰了很多

那就是类型匹配问题不会存在于“某个数据类型”与另一个数据类型之间

如某种接口类型与某种实现了这个接口的接口体类型之间
再如某个被type的数据类型和被type后的（别名）数据类型类型之间

类型匹配问题只存在于各个不同数据类型的实体变量间的赋值与被赋值之间的逻辑联系

因此其实只需要去验证几个事:

1.type一个非接口类数据类型与原始数据类型，两者变量实体间的类型匹配问题
2.type一个接口类数据类型，与原始接口类数据类型，两者变量实体间的类型匹配问题
3.type一个接口类数据类型，与实现了这个新接口的结构体，两者变量实体间的类型匹配问题
4.type一个接口类数据类型，与实现了旧接口的结构体，两者变量实体间的类型匹配问题（似乎和3在书写上没有区别啊）
5.type一个接口类数据类型，找到这个实现了新接口的结构体，并type出一个新结构体，新接口与新结构体两者变量实体间的类型匹配问题

总结：

结构类和这个结构类别名之间无法实现类型匹配，结构体之间类型匹配的使用是被语言禁止的，没有任何灵活性可言

而接口与接口之间，接口与结构类之间存在者巨大的灵活性：

首先type后的接口与原始接口之间是可以相互赋值的，然后如果一个结构类实现了这个结构，则无论是type后的还是旧接口都可以单向进行类型匹配

interface变量<->另一个field与其完全1相同的interface变量<->type后的接口别名<-实现了他们的结构类

彻底折腾明白了，类型匹配的核心部件是其实是接口