Go反射根本无法调用未导出方法，因编译器在生成反射元数据时已彻底剔除所有未导出方法，MethodByName返回零值是正常现象，必须先检查IsValid()和Kind()再调用。
Go 反射根本无法调用未导出方法
你不能绕过，不是“限制太严”，而是 Go 编译器在生成反射元数据时就彻底剔除了所有未导出方法。reflect.Type.Method()、reflect.Value.MethodByName()、reflect.Value.Method() 这些 API 返回的永远只包含首字母大写的导出方法——它们压根不存在于反射信息里。试图用 unsafe 或字段偏移去“找”未导出方法的函数指针，属于未定义行为：不同 Go 版本的内部布局可能变化，runtime 也不承诺保留这些细节。
MethodByName("xxx") 返回零值是正常现象，不是 bug
当你写 v.MethodByName("helper") 而 helper 是小写开头的方法时，返回的是一个 reflect.Value 零值（IsValid() == false）。这不是调用失败，而是“查无此方法”。常见错误是跳过有效性检查直接 .Call()，结果 panic：call of reflect.Value.Call on zero Value。
- 必须先判断
method.IsValid() && method.Kind() == reflect.Func - 不要依赖
method.Name[0] >= 'A'做二次过滤——Unicode 导出名如Écho会误判 - 调试时可用
v.NumMethod()遍历全部导出方法名，确认目标是否在其中
想测试未导出方法？别碰反射，改包声明
单元测试要覆盖 func (s *Svc) validate() error，正确做法是让测试文件和生产代码同属一个包，即测试文件声明 package svc（而非 package svc_test），同时保持文件名仍为 svc_test.go。这样就能自然调用未导出方法，无需反射、不破坏封装、不引入 unsafe。
- 同包测试是 Go 官方推荐路径，
go test完全支持 - 如果测试必须跨包（如集成测试），应暴露导出接口或调度方法，例如
Run(action string, args interface{}) - 用
//go:build ignore不解决访问问题，只是让文件不参与构建
强行用 unsafe + reflect 调用未导出方法等于放弃维护性
技术上存在极少数 hack 方式（比如通过解析 runtime._type 或遍历结构体字段推测方法地址），但这类代码：
立即学习“go语言免费学习笔记（深入）”；
- Go 官方明确不保证兼容性，升级后大概率崩溃
- 静态分析工具（如
staticcheck）会报SA1019警告 - CI 流程中可能被直接拦截，团队协作成本极高
- 它绕过的不是“反射限制”，而是整个语言的可见性契约
真正需要动态分发逻辑的地方，应该设计导出的接口或方法，而不是在运行时钻编译器空子。
