Go反射无法调用私有方法，因编译器在类型元信息中彻底剔除私有方法，其不在Methods()列表中且MethodByName返回无效Value；同包内亦失败，因导出规则是编译期语义；unsafe绕过将触发vet警告或崩溃；应通过重构逻辑、接口抽象或黑盒测试替代。
Go 反射根本不能调用私有方法
直接结论：reflect.Value.MethodByName("privateMethod") 返回的 reflect.Value 一定无效（.IsValid() 为 false），后续调用 .Call() 必 panic：panic: reflect: Call of nil Value。这不是环境配置、版本或写法问题，而是 Go 编译器在构建类型元信息时就彻底剔除了私有方法——它们不在 reflect.Type.Methods() 列表里，也不出现在 reflect.Type.NumMethod() 计数中。
为什么同包内也失败
常见误判是“我在同一个包里，应该能反射到”。但 Go 的导出规则（首字母大小写）是编译期语义，和源码物理位置无关。即使你在 user.go 和 user_test.go 同一包下写反射代码：reflect.ValueOf(u).MethodByName("greet")（greet 小写）依然返回无效值。因为 greet 的符号根本没被写入 runtime 类型结构体的 method table，反射系统连它的函数指针地址都拿不到。
试图绕过会触发 vet 或崩溃
用 unsafe 手动拼凑函数调用、通过 runtime 包读取未导出方法地址、或依赖调试器注入——这些操作在 Go 1.22+ 中会被 go vet 主动标记为可疑模式；更大概率在 GC 标记阶段、内联优化后或不同架构上直接 crash。标准库明确禁止这类行为，且不提供任何稳定 ABI 接口供外部 unsafe 调用。
真正可行的测试替代路径
需要验证私有逻辑？别碰反射，改代码结构：
立即学习“go语言免费学习笔记（深入）”；
- 把核心逻辑抽成包级小写函数（如
func validateEmail(s string) bool），测试文件可直接调用 - 为结构体定义导出接口（如
type Validator interface { Validate() error }），让私有方法实现它，测试时用接口断言 - 在测试文件中导出临时方法（如
func (u *User) TestValidate() error），仅限_test.go使用，生产构建不受影响 - 接受“私有即不可测”——专注用黑盒方式测试导出方法的输入/输出边界，这反而暴露设计缺陷更早
最易忽略的一点：连 struct 字段的反射访问也受同样限制，且 json 包能序列化私有字段是因为它走的是底层内存复制路径，不是反射 API —— 别把特例当通用能力。
