Go 反射无法调用非导出方法
直接说结论：reflect.Value.Call 对非导出（小写开头）方法会 panic，错误信息是 call of reflect.Value.Call on unexported method。这不是限制太严，而是 Go 语言在反射层就做了硬性拦截 —— 运行时根本不会让你拿到那个方法的 reflect.Method，更别说调用了。
为什么 reflect.Value.MethodByName 找不到非导出方法
Go 的反射模型严格遵循导出规则：只有导出标识符（首字母大写）才进入 reflect.Type 的公开视图。即使你用 t.NumMethod() 能看到方法总数，t.Method(i) 返回的也是过滤后的导出方法列表。
常见错误现象：
- 打印
t.NumMethod()得到 3，但t.MethodByName("foo")返回零值 —— 因为foo是非导出的 - 试图用
reflect.ValueOf(&s).MethodByName("bar")获取后调用，结果 panic
绕过？不存在合法绕过
网上有些“黑科技”方案，比如用 unsafe 强制读取结构体内存、伪造函数指针、甚至 patch runtime —— 这些要么在新版本 Go 直接崩溃，要么触发 vet 检查、被 go toolchain 拒绝编译，或导致 GC 失控。
立即学习“go语言免费学习笔记（深入）”；
真实可用的替代路径只有这些：
- 把方法改成导出（首字母大写），这是唯一稳定、可维护、符合 Go 约定的做法
- 如果必须隐藏实现细节，改用组合 + 接口：定义导出接口，内部用非导出结构体实现，再通过工厂函数返回接口实例
- 测试场景下，可通过
test包内访问（同包即可），无需反射 —— 非导出方法本就对同包代码可见
容易被忽略的关键点
很多人卡在“为什么 struct 字段能反射读写，方法却不行”，本质区别在于：字段访问走的是内存偏移计算（unsafe 层面可控），而方法调用必须经过类型系统的方法集检查，这个检查在反射入口就完成了，没机会绕开。
另外，go:linkname 或 go:build ignore 类 hack 方式，在模块化构建和 vendor 场景下极易失效，上线前极难覆盖验证。
