不过，这种通过嵌入其他接口类型来创建新接口类型的方式，在 Go 1.14 版本之前是有约束的：如果新接口类型嵌入了多个接口类型，这些嵌入的接口类型的方法集合不能有交集，同时嵌入的接口类型的方法集合中的方法名字，也不能与新接口中的其他方法同名。比如我们用 Go 1.12.7 版本运行下面例子，Go 编译器就会报错：
我们可以看到，原本结构体类型 T 只带有一个方法 M3，但在嵌入接口类型 I 后，结构体类型 T 的方法集合中又并入了接口类型 I 的方法集合。并且，由于 *T 类型方法集合包括 T 类型的方法集合，因此无论是类型 T 还是类型 *T，它们的方法集合都包含 M1、M2 和 M3。于是我们可以得出一个结论：结构体类型的方法集合，包含嵌入的接口类型的方法集合。
不过有一种情况，你要注意一下，那就是当结构体嵌入的多个接口类型的方法集合存在交集时，你要小心编译器可能会出现的错误提示。
虽然Go 1.14 版本解决了嵌入接口类型的方法集合有交集的情况，但那仅限于接口类型中嵌入接口类型，这里我们说的是在结构体类型中嵌入方法集合有交集的接口类型。
根据我们前面讲的，嵌入了其他类型的结构体类型本身是一个代理，在调用其实例所代理的方法时，Go 会首先查看结构体自身是否实现了该方法。
如果实现了，Go 就会优先使用结构体自己实现的方法。如果没有实现，那么 Go 就会查找结构体中的嵌入字段的方法集合中，是否包含了这个方法。如果多个嵌入字段的方法集合中都包含这个方法，那么我们就说方法集合存在交集。这个时候，Go 编译器就会因无法确定究竟使用哪个方法而报错，下面的这个例子就演示了这种情况：
type E1 interface {
M1()
M2()
M3()
}
type E2 interface {
M1()
M2()
M4()
}
type T struct {
E1
E2
}
func main() {
t := T{}
t.M1()
t.M2()
}
复制代码
运行这个例子，我们会得到：
main.go:22:3: ambiguous selector t.M1
main.go:23:3: ambiguous selector t.M2
复制代码
我们看到，Go 编译器给出了错误提示，表示在调用 t.M1 和 t.M2 时，编译器都出现了分歧。在这个例子中，结构体类型 T 嵌入的两个接口类型 E1 和 E2 的方法集合存在交集，都包含 M1 和 M2，而结构体类型 T 自身呢，又没有实现 M1 和 M2，所以编译器会因无法做出选择而报错。
那怎么解决这个问题呢？其实有两种解决方案。一是，我们可以消除 E1 和 E2 方法集合存在交集的情况。二是为 T 增加 M1 和 M2 方法的实现，这样的话，编译器便会直接选择 T 自己实现的 M1 和 M2，不会陷入两难境地。比如，下面的例子演示的就是 T 增加了 M1 和 M2 方法实现的情况：
在前面结构体类型中嵌入结构体类型，为 Gopher 们提供了一种“实现继承”的手段，外部的结构体类型 T 可以“继承”嵌入的结构体类型的所有方法的实现。并且，无论是 T 类型的变量实例还是 *T 类型变量实例，都可以调用所有“继承”的方法。但这种情况下，带有嵌入类型的新类型究竟“继承”了哪些方法，我们还要通过下面这个具体的示例来看一下。
它们作为嵌入字段嵌入到 T 中后，对 T 和 *T 的方法集合的影响也是不同的。我们运行一下这个示例，看一下输出结果：
main.T's method set:
- PT2M2
- T1M1
- T2M1
*main.T's method set:
- PT1M2
- PT2M2
- T1M1
- T2M1
复制代码
通过输出结果，我们看到了 T 和 *T 类型的方法集合果然有差别的：
类型 T 的方法集合 = T1 的方法集合 + *T2 的方法集合
类型 *T 的方法集合 = *T1 的方法集合 + *T2 的方法集合
这里，我们尤其要注意 *T 类型的方法集合，它包含的可不是 T1 类型的方法集合，而是 *T1 类型的方法集合。这和结构体指针类型的方法集合包含结构体类型方法集合，是一个道理。
到这里，基于类型嵌入“继承”方法实现的原理，我们基本都清楚了。但不知道你会不会还有一点疑惑：只有通过类型嵌入才能实现方法“继承”吗？如果我使用类型声明语法基于一个已有类型 T 定义一个新类型 NT，那么 NT 是不是可以直接继承 T 的所有方法呢？
八、defined 类型与 alias 类型是否可以实现方法集合的“继承”？
8.1 defined 类型与 alias 类型的方法集合
Go 语言中，凡通过类型声明语法声明的类型都被称为 defined 类型，下面是一些 defined 类型的声明的例子：
type I interface {
M1()
M2()
}
type T int
type NT T // 基于已存在的类型T创建新的defined类型NT
type NI I // 基于已存在的接口类型I创建新defined接口类型NI
复制代码
新定义的 defined 类型与原 defined 类型是不同的类型，那么它们的方法集合上又会有什么关系呢？新类型是否“继承”原 defined 类型的方法集合呢？
这个问题，我们也要分情况来看。
对于那些基于接口类型创建的 defined 的接口类型，它们的方法集合与原接口类型的方法集合是一致的。但对于基于非接口类型的 defined 类型创建的非接口类型，我们通过下面例子来看一下：
package main
type T struct{}
func (T) M1() {}
func (*T) M2() {}
type T1 T
func main() {
var t T
var pt *T
var t1 T1
var pt1 *T1
dumpMethodSet(t)
dumpMethodSet(t1)
dumpMethodSet(pt)
dumpMethodSet(pt1)
}
复制代码
在这个例子中，我们基于一个 defined 的非接口类型 T 创建了新 defined 类型 T1，并且分别输出 T1 和 *T1 的方法集合来确认它们是否“继承”了 T 的方法集合。
运行这个示例程序，我们得到如下结果：
main.T's method set:
- M1
main.T1's method set is empty!
*main.T's method set:
- M1
- M2
*main.T1's method set is empty!
复制代码
从输出结果上看，新类型 T1 并没有“继承”原 defined 类型 T 的任何一个方法。从逻辑上来说，这也符合 T1 与 T 是两个不同类型的语义。
基于自定义非接口类型的 defined 类型的方法集合为空的事实，也决定了即便原类型实现了某些接口，基于其创建的 defined 类型也没有“继承”这一隐式关联。也就是说，新 defined 类型要想实现那些接口，仍然需要重新实现接口的所有方法。
那么，基于类型别名（type alias）定义的新类型有没有“继承”原类型的方法集合呢？我们还是来看一个例子：
