Go 的 reflect 包在运行时仅暴露已导出（首字母大写）的方法，因此无需额外判断——未导出方法根本不会出现在 Type.Methods() 结果中，这是语言层面的反射安全机制。
go 的 `reflect` 包在运行时仅暴露已导出（首字母大写）的方法，因此无需额外判断——未导出方法根本不会出现在 `type.methods()` 结果中，这是语言层面的反射安全机制。
在 Go 中，“内部方法”即未导出方法（以小写字母开头），其可见性由编译器在包级别强制约束。值得注意的是：这种导出性（exportedness）并非运行时属性，而是编译期语义；reflect 包严格遵循该规则，在运行时完全屏蔽未导出方法。
这意味着：当你使用 reflect.TypeOf(t).Method(i) 或遍历 reflect.TypeOf(t).NumMethod() 获取方法列表时，返回的所有 reflect.Method 均天然为已导出方法。未导出方法不会被包含在内，也不可通过 reflect.Value.Method() 等方式访问——尝试访问将导致 panic（如 panic: reflect: Call of unexported method）。
✅ 正确做法：直接遍历 reflect.Type.Methods()，无需额外名称校验
func bindMethodsToHandlers(obj interface{}) {
t := reflect.TypeOf(obj)
v := reflect.ValueOf(obj)
for i := 0; i <p>⚠️ 注意事项： </p>
- ❌ 不要依赖
strings.HasPrefix(method.Name, "_")或正则匹配“内部命名约定”——Go 的导出性仅由首字母大小写决定，下划线前缀无语言意义； - ❌ 不要尝试通过
reflect.Value的CanInterface()或CanAddr()判断导出性——这些反映的是可访问性（如是否可取地址），与导出性无关； - ✅ 若需跳过特定已导出方法（如
Reset,Clone等逻辑上“内部”的工具方法），应基于业务命名约定或自定义标签（如//go:generate注释或结构体字段 tag），而非混淆导出性概念。
总结：Go 的反射模型与导出机制深度协同——“能被 reflect 看到，即意味着它是公开的”。这既是设计使然，也是最佳实践基础：你无需、也不应试图在运行时“探测”未导出方法的存在；只需信任 reflect.Type.Methods() 的结果，它天然过滤了所有内部方法。
