go 作为静态类型语言不支持运行时方法存在性动态查询，但可通过接口类型断言或反射机制安全、高效地实现类似 objective-c `respondstoselector:` 的功能。
在 go 中，没有内置的 respondsToSelector: 这类动态方法检测机制，因为其设计哲学强调编译期类型安全与显式契约。但实际开发中（如编写通用工具函数、适配器或插件系统），我们常需判断某个值是否具备某方法能力。Go 提供两种主流、符合惯用法的解决方案：接口类型断言（推荐）和 reflect 包反射检查（按需使用）。
✅ 推荐方式：窄接口 + 类型断言（类型安全、高效、可读性强）
Go 的核心思想是“鸭子类型”——关注行为而非类型。因此，最地道的做法是定义一个仅包含目标方法的最小接口，再通过类型断言验证实现：
// 定义仅关心的单个方法接口 type HasRun interface { Run() error } // 使用示例 func executeIfRunnable(v interface{}) error { if r, ok := v.(HasRun); ok { return r.Run() // 安全调用 } return fmt.Errorf("value does not implement Run() method") }你甚至可以内联声明接口，避免额外命名（适合一次性检查）：
if runner, ok := v.(interface{ Run() error }); ok { return runner.Run() }✅ 优势：零反射开销、编译期可部分验证、语义清晰、符合 Go idioms。
⚠️ 注意：该方法要求目标类型显式实现该接口（哪怕未显式声明 type T Struct{} 实现 HasRun，只要方法签名匹配即可满足隐式实现）。
⚠️ 备选方式：reflect 包动态检查（灵活但谨慎使用）
当无法预知方法名（如从字符串配置加载）、需泛化处理大量未知方法，或处于调试/框架底层时，可借助 reflect：
import "reflect" func hasMethod(obj interface{}, methodName string) (bool, reflect.Method) { t := reflect.TypeOf(obj) // 注意：若 obj 是指针，需取 Elem()；若为值类型，直接使用 if t.Kind() == reflect.Ptr { t = t.Elem() } method, ok := t.MethodByName(methodName) return ok, method } // 使用示例 v := strings.Builder{} if ok, m := hasMethod(v, "WriteString"); ok { // 获取方法值并调用（需构造参数切片） results := m.Func.Call([]reflect.Value{ reflect.ValueOf(&v), // 接收者（注意传指针） reflect.ValueOf("hello"), // 第一个参数 }) fmt.Println(results[0].Int()) // 写入字节数 }⚠️ 重要注意事项：
- 反射性能显著低于类型断言，禁止在热路径高频使用；
- MethodByName 仅查找已导出（大写开头）方法，私有方法不可见；
- 调用反射方法需手动构造 reflect.Value 参数，易出错且丧失类型安全；
- 接收者类型必须匹配：值方法只能对值调用，指针方法通常需指针接收者（reflect.ValueOf(&v)）。
总结与最佳实践
| 场景 | 推荐方案 | 理由 |
|---|---|---|
| 明确知道需检查的方法签名（如 Close(), Encode()） | 窄接口 + 类型断言 | 零开销、类型安全、代码自文档化 |
| 方法名来自配置、用户输入或高度泛化框架逻辑 | reflect.MethodByName | 必要灵活性，但应封装隔离、添加缓存（如 sync.map 缓存 reflect.Type） |
| 检查多个方法是否存在 | 组合多个窄接口断言，或统一定义复合接口 | 避免过度依赖反射，保持可维护性 |
归根结底，Go 鼓励你提前约定行为契约（接口），而非运行时试探。优先设计小而精的接口，并让调用方显式满足它——这比“检查再调用”更健壮、更高效，也更 Go。