reflect.Value.MethodByName("privateMethod") 返回的 reflect.Value 必定 .IsValid() == false，因私有方法未进入 runtime 类型结构体 method table，反射无入口可寻，任何 .Call() 均 panic。
reflect.MethodByName("privateMethod") 一定返回无效值
直接结论：reflect.Value.MethodByName("privateMethod") 返回的 reflect.Value 必定 .IsValid() == false，后续任何 .Call() 都会 panic：「panic: reflect: Call of nil Value」。这不是写法问题，也不是版本差异——Go 编译器在生成类型元信息时，就彻底不把私有方法写入 reflect.Type.Methods() 列表，NumMethod() 也不计数。运行时反射系统连函数指针地址都拿不到，自然无法调用。
同包内反射访问私有方法同样失败
常见误解是“我在同一包里，应该能反射到”。但 Go 的导出规则（首字母大小写）是编译期语义，与文件物理位置无关。哪怕 user.go 和 user_test.go 同属 user 包，reflect.ValueOf(u).MethodByName("greet")（greet 小写）依然返回无效值。因为该符号根本没进入 runtime 类型结构体的 method table，反射 API 没有入口可寻。
unsafe 强行绕过会触发 vet 警告或运行时崩溃
试图用 unsafe 拼凑函数调用、读取未导出方法地址、或依赖调试器注入：
- Go 1.22+ 中
go vet会主动标记为可疑模式 - GC 标记阶段、内联优化后、或跨架构（如 arm64 vs amd64）极易 crash
- 标准库不提供稳定 ABI 接口，所有此类操作属于未定义行为（undefined behavior）
尤其注意：自 Go 1.17 起，对私有字段的反射修改已被彻底禁止；方法层面虽无显式 panic，但底层支撑已移除，强行操作只会让程序更不可靠。
立即学习“go语言免费学习笔记（深入）”；
真正可行的替代路径只有三条
需要验证私有逻辑？别碰反射，改代码结构：
- 把核心逻辑抽成包级小写函数（如
func validateEmail(s string) bool），测试文件可直接调用 - 为结构体定义导出接口（如
type Validator interface { Validate() error }），让私有方法实现它，测试时用接口断言 - 在
_test.go文件中导出临时方法（如func (u *User) TestValidate() error），仅限测试构建使用，生产二进制完全不包含
最易忽略的一点：json 包能序列化私有字段，是因为它走的是底层内存复制路径，不是反射 API——别把特例当通用能力。封装性不是障碍，而是设计意图的显式表达。
