在 Go 语言中，结构体嵌入让类型组合变得很直接。把 Inner 嵌进 Outer 后，Inner 的导出方法会自动提升为 Outer 的方法。可一旦 Outer 自己也定义了同名方法，Inner 的方法就被遮蔽，直接调用 o.Hello() 只会得到外层实现。这个规则对代码组织和接口隐式实现影响很大。编译器并没有删除内层方法，只是在方法查找时选择了最外层声明。理解这一点后，反射访问被遮蔽的方法就有一条清晰路径：绕开类型的方法集提升，从嵌入字段对应的 reflect.Value 上重新执行方法查找。下面先给出一个基础示例，再逐步展开反射方案。
一、方法提升与遮蔽规则
结构体嵌入是 Go 语言实现组合复用的核心语法。当我们在一个结构体中声明一个匿名字段时，该字段类型的所有导出方法都会提升到外层结构体的方法集里。例如 Inner 定义了 Hello 方法，那么 Outer 即使不显式声明，也拥有了 Hello 方法。这种机制让接口实现变得非常轻量，也让小型类型可以像积木一样拼装出更复杂的行为。
遮蔽发生在同名方法出现时。如果 Outer 也定义一个 Hello 方法，那么在 Outer 的方法集里，Hello 指向 Outer.Hello，而不是 Inner.Hello。直接使用 o.Hello() 时，编译器按最外层优先的规则选择方法，因此得到的是外层实现。但内层方法仍然可以通过显式字段访问，例如 o.Inner.Hello()，这说明遮蔽并不等于删除，只是改变了默认查找顺序。
package main
import "fmt"
type Inner struct{}
func (Inner) Hello() string {
return "inner hello"
}
type Outer struct {
Inner
}
func (o Outer) Hello() string {
return "outer hello"
}
func main() {
o := Outer{}
fmt.Println(o.Hello()) // 输出：outer hello
fmt.Println(o.Inner.Hello()) // 输出：inner hello
}
从方法集角度看，Outer 的 Hello 方法签名是 func(Outer) string，而 Inner 的 Hello 是 func(Inner) string。两者接收者类型完全不同，却被提升规则压缩进了同一个外层类型。日常调用时这种遮蔽通常是我们期望的，它可以覆盖内层默认行为；但如果需要编写通用工具，例如调试器或对象检查器，就不得不处理被遮蔽的方法。
二、反射默认行为与字段路径
反射包 reflect 提供了与编译器规则一致的方法查找能力。对一个外层结构体调用 Type.MethodByName 时，返回的是该类型方法集中的方法，也就是被外层声明遮蔽之后的结果。也就是说，即使你能看到内层字段，reflect.TypeOf(Outer{}) 的 MethodByName("Hello") 依然只会返回 Outer.Hello。这一点在反射调试中经常造成误解，很多人以为反射能自动拿到被遮蔽的方法，其实并不能。
package main
import (
"fmt"
"reflect"
)
type Inner struct{}
func (Inner) Hello() string { return "inner hello" }
type Outer struct {
Inner
}
func (o Outer) Hello() string { return "outer hello" }
func main() {
o := Outer{}
t := reflect.TypeOf(o)
m, _ := t.MethodByName("Hello")
fmt.Printf("方法名称: %s\n", m.Name)
fmt.Printf("方法类型: %s\n", m.Type)
}
上面代码输出的是 func(main.Outer) string，而不是 func(main.Inner) string。要绕过这个限制，需要手动访问嵌入字段。结构体的字段信息可以通过 Type.Field(i) 获取，其中匿名字段的 Anonymous 属性为 true。字段本身又带有 Type，所以可以针对字段类型执行 MethodByName。但仅拿到 reflect.Method 还不能调用，必须进一步通过外层值定位到内层字段的值。
获取内层字段值可以使用 Value.FieldByIndex。这里要注意可寻址性：如果使用 reflect.ValueOf(o)，得到的值不可寻址，后续调用指针接收者方法时会受到限制。推荐写法是通过 reflect.ValueOf(&o).Elem() 取得一个可寻址的外层结构体值，再按字段索引获取嵌入字段。单层嵌入的完整访问流程如下。
package main
import (
"fmt"
"reflect"
)
type Inner struct{}
func (Inner) Hello() string { return "inner hello" }
type Outer struct {
Inner
}
func (o Outer) Hello() string { return "outer hello" }
func main() {
o := Outer{}
v := reflect.ValueOf(&o).Elem()
t := v.Type()
for i := 0; i < t.NumField(); i++ {
f := t.Field(i)
if !f.Anonymous {
continue
}
fv := v.FieldByIndex(f.Index)
if m := fv.MethodByName("Hello"); m.IsValid() {
result := m.Call(nil)
fmt.Println(result[0].String()) // 输出：inner hello
}
}
}
这段代码先检查字段是否为匿名字段，再通过 FieldByIndex 拿到字段值。字段值的 MethodByName 不会再受到外层遮蔽影响，因为它直接基于 Inner 类型做查找。调用 Call(nil) 后，返回值是一个 []reflect.Value，这里只有一个字符串结果，取索引 0 并转成字符串即可。
三、递归处理多层嵌入和指针嵌入
实际项目中的嵌入关系往往不止一层。一个结构体可能嵌入了另一个结构体，而被嵌入的结构体内部又嵌入了更底层的类型。如果在每一层都定义了同名方法，那么最外层调用只会命中最外层声明，中间层和底层的方法都被逐层遮蔽。要完整访问所有被遮蔽的方法，单层遍历显然不够，需要递归地检查所有匿名字段。
指针嵌入也很常见，例如 Outer 里面写 *Mid 而不是 Mid。指针字段的方法集包含值接收者和指针接收者方法，但调用之前必须先解引用，并且要防止空指针导致程序崩溃。下面给出一个递归函数，它能罗列调用链上所有被遮蔽的同名方法。
package main
import (
"fmt"
"reflect"
)
type Base struct{}
func (Base) Ping() string { return "base ping" }
type Mid struct {
Base
}
func (Mid) Ping() string { return "mid ping" }
type Outer2 struct {
Mid
}
func (o Outer2) Ping() string { return "outer2 ping" }
func findShadowed(v reflect.Value, name string) []string {
var results []string
t := v.Type()
for i := 0; i < t.NumField(); i++ {
f := t.Field(i)
if !f.Anonymous {
continue
}
fv := v.FieldByIndex(f.Index)
if fv.Kind() == reflect.Ptr {
if fv.IsNil() {
continue
}
fv = fv.Elem()
}
if m := fv.MethodByName(name); m.IsValid() {
out := m.Call(nil)
if s, ok := out[0].Interface().(string); ok {
results = append(results, s)
}
}
if fv.Kind() == reflect.Struct {
results = append(results, findShadowed(fv, name)...)
}
}
return results
}
func main() {
o := Outer2{}
v := reflect.ValueOf(&o).Elem()
fmt.Println(findShadowed(v, "Ping"))
}
上面的递归函数从当前结构体开始，逐个检查匿名字段。如果字段是指针，先做空判断再解引用；然后尝试调用目标方法；如果字段解引用后仍然是结构体，就继续向下递归。这样 Mid.Ping 和 Base.Ping 都能被找到，而不会因为 Outer2.Ping 的存在被掩盖。输出结果通常与字段定义和递归顺序有关，但它不改变各层类型的实际方法归属。
需要注意的是，递归函数最好保持对返回值的类型断言宽容。如果方法返回的不是字符串，或者接收者带有副作用，调用时要考虑错误处理。生产级代码还应该限制递归深度，避免异常结构体导致栈溢出。对于大多数业务嵌入场景，两层或三层已经足够，简单的递归足够应付。
四、边界情况与工程实践
反射访问被遮蔽方法时，可寻址性是最常见的陷阱。直接使用 reflect.ValueOf(o) 得到的是不可寻址值，若内层方法使用指针接收者，调用会失败。务必使用 reflect.ValueOf(&o).Elem() 来确保整个值和字段值都可寻址。这个细节与编译器自动取地址的行为类似，但反射不会自动帮你做这件事，需要显式控制。
嵌入指针为 nil 是另一个需要提前处理的边界。即使外层结构体本身正常，匿名字段如果是指针类型且没有初始化，直接调用其方法也会触发空指针。反射代码中应先检查 fv.Kind() == reflect.Ptr 以及 fv.IsNil()，再决定是否继续。对于未导出字段，跨包访问时 Interface 方法会受到限制，虽然 MethodByName 可能仍然返回方法，但实际工程中应当尽量避免依赖未导出成员。
还有一个容易混淆的问题是歧义嵌入。如果两个嵌入字段都定义了同名方法，而外层没有定义，那么直接使用 o.Hello() 会编译失败，因为方法提升后来源不唯一。但反射没有这个问题，它可以通过不同字段路径分别定位到两个实现，这在某些诊断工具中反而更有用。反射绕过编译期歧义检查，意味着你要对代码行为有更明确的预期，否则很容易写出难以维护的逻辑。
在框架设计、序列化、ORM 或调试工具中，访问被遮蔽方法确实有实际价值。例如某些注册钩子可能隐藏在嵌入的基础类型中，外层为了扩展覆盖了同名入口，但初始化流程仍需要调用底层版本。反射提供了一种通用方式去发现和调用这些方法。不过正常业务代码如果没有通用性要求，直接使用 o.Inner.Hello() 更清晰，也更容易被静态分析工具识别。反射应该留在真正需要解耦和通用化的地方。