go反射无法访问结构体私有字段或方法，因编译期已剥离私有成员的反射信息；fieldbyname和methodbyname均返回无效值，且不报错。
Go 反射无法访问结构体私有字段或方法
直接结论：reflect 包不能获取、调用或修改结构体的私有（小写开头）字段和方法。这不是权限问题，而是 Go 编译器在编译期就将私有成员从反射信息中完全剥离——reflect.Value.FieldByName("privateField") 返回零值，reflect.Value.MethodByName("privateMethod") 返回无效值（IsValid() == false），且不会报错，只会静默失败。
为什么 reflect 不能访问私有成员
Go 的反射设计严格遵循包级可见性规则：反射操作仅能触及“运行时可导出”的成员，而是否导出（exported）由标识符首字母大小写决定，与 struct 定义位置无关。即使你在同一包内使用 reflect，也无法绕过该限制。
- 私有字段在
reflect.Type.NumField()中被计入，但reflect.Type.Field(i).PkgPath非空，表示它不可导出；调用reflect.Value.Field(i)会 panic：“cannot set unexported field” 或返回零值 - 私有方法不会出现在
reflect.Type.NumMethod()结果中，reflect.Type.MethodByName("xxx")直接返回空reflect.Method - 这种限制在
go build阶段已固化，不是运行时权限检查，因此无法通过 unsafe 或其他方式绕过
替代方案：用公开接口或标签暴露必要能力
若需在不破坏封装的前提下支持反射式访问，应主动提供导出的访问层，而非强求反射穿透私有边界。
- 为结构体添加导出方法，如
GetPrivateField() interface{}或CallPrivateLogic() error，内部实现对私有成员的操作 - 用 struct tag 标记字段意图（如
json:"name" reflect:"readable"），再配合自定义逻辑判断哪些导出字段对应哪些私有语义 - 若用于序列化/调试等场景，优先使用标准库已支持的方式：比如
json包可序列化私有字段（只要其类型可导出），因为它不依赖reflect.Value.FieldByName，而是走特殊路径 - 避免在测试中滥用反射读写私有字段——应通过构造函数、选项模式或测试友好的导出方法来控制状态
常见误判：以为同包就能反射私有成员
这是最常踩的坑。写个 demo 就清楚：
type User struct {
name string // 私有
Age int // 导出
}
func (u *User) greet() string { return "hi" } // 私有方法
func (u *User) Greet() string { return u.greet() } // 导出方法，内部调用私有
此时：
-
reflect.ValueOf(&u).Elem().FieldByName("name")→ 无效值（IsValid()==false） -
reflect.ValueOf(&u).Elem().MethodByName("greet")→ 无效值 -
reflect.ValueOf(&u).Elem().MethodByName("Greet").Call(nil)→ ✅ 可调用，返回 "hi" -
reflect.TypeOf(User{}).FieldByName("name").PkgPath→ 返回非空字符串（如 "main"），表明不可导出
真正要小心的是那些看似成功却返回零值的操作——它们不 panic，但结果不可靠，容易埋下隐性 bug。
