Go 语言虽无 Ruby 那样直接调用 obj.methods 的语法糖，但可通过 reflect.TypeOf() 获取类型信息并遍历其公开方法，实现类似功能。本文详解如何安全、规范地使用反射枚举方法，并指出典型适用场景与替代方案。
go 语言虽无 ruby 那样直接调用 `obj.methods` 的语法糖，但可通过 `reflect.typeof()` 获取类型信息并遍历其公开方法，实现类似功能。本文详解如何安全、规范地使用反射枚举方法，并指出典型适用场景与替代方案。
在 Go 中，没有内置的 .methods 方法，因为 Go 的设计哲学强调显式性与编译时确定性——方法集在编译期即已固定，运行时动态探查并非惯用模式。但当确实需要在运行时检查类型能力（如调试、泛型适配、插件系统或序列化框架开发）时，标准库 reflect 提供了可靠支持。
✅ 正确获取方法列表的方式
核心是使用 reflect.TypeOf() 获取类型的 reflect.Type，再调用 NumMethod() 和 Method(i) 遍历：
package main
import (
"fmt"
"reflect"
)
type User struct {
Name string
}
func (u User) Greet() string { return "Hello, " + u.Name }
func (u *User) Save() error { return nil }
func (u User) private() {} // 非导出方法（首字母小写）不会出现在 Method 列表中
func main() {
t := reflect.TypeOf(User{}) // 注意：传入值类型实例
fmt.Printf("Methods on %v:\n", t)
for i := 0; i < t.NumMethod(); i++ {
m := t.Method(i)
fmt.Printf("- %s (signature: %s)\n", m.Name, m.Type.String())
}
}
// 输出：
// Methods on main.User:
// - Greet (signature: func(main.User) string)⚠️ 关键注意事项：
- 只有导出（首字母大写）的方法会被 Method() 返回；私有方法完全不可见。
- reflect.TypeOf(x) 接收的是值或指针，但返回的是该值的静态类型。若传 *User{}，则 t 是 *User 类型，其方法集包含 (User).Greet 和 (*User).Save —— 但 (*User).Greet 并不存在（因 Greet 是值接收者），此时 NumMethod() 仍会返回 2 个方法（Go 自动提升值接收者方法到指针类型方法集）。
- 若需获取指针类型的方法集（例如检查 *User 能调用哪些方法），应显式使用 reflect.TypeOf((*User)(nil)).Elem() 或直接传 *User{}。
? 什么情况下不该用反射？
-
日常业务逻辑判断：比如“这个变量有没有 Close() 方法？”——应优先用接口断言：
if closer, ok := anyObj.(io.Closer); ok { closer.Close() } -
验证接口实现：编译期即可检测，无需运行时反射：
var _ io.Writer = (*MyWriter)(nil) // 编译失败即提示未实现 Write
? 更实用的替代思路
| 场景 | 推荐方式 |
|---|---|
| 检查是否实现某接口 | 类型断言或空接口赋值验证 |
| 自动生成文档/SDK | 使用 go/doc 包解析 AST（静态分析，更准确） |
| 构建通用 ORM 或序列化器 | 结合 reflect.StructTag 解析字段标签，而非仅依赖方法名 |
总之，reflect.TypeOf(t).Method(i) 是 Go 中最接近 Ruby obj.methods 的机制，但它不是“调试快捷键”，而是一个需谨慎使用的底层工具。务必明确需求：若目标是类型安全与可维护性，请拥抱接口与编译检查；若确需动态能力（如框架开发），则应配合充分测试与文档说明其反射行为边界。
