Go反射无法安全修改私有字段，因设计上禁止访问未导出字段；FieldByName对小写字段静默返回无效值，且recover无法捕获其panic，根本原因是编译期已移除私有标识符元数据。
Go 反射机制中不存在“捕获未定义行为”这回事——reflect 对私有字段、不可寻址值、非法调用等场景的响应是明确且静默的，不是运行时异常，无法用 recover 拦截，也谈不上“降级”。你试图让反射穿透封装时，得到的只是无效值或 panic，而不是可兜底的错误流。
FieldByName 为什么静默返回零值，而不是 panic？
因为 Go 编译器在构建阶段就从反射元数据中彻底移除了所有未导出标识符（首字母小写）的信息。reflect.Value.FieldByName("name") 查不到该字段，只能返回一个 .IsValid() == false 的零值。这不是 bug，是语言设计强制的可见性隔离。
常见误判是看到 v.Field(0).Interface() 输出了值，就以为“读到了私有字段”——那只是同包内极不稳定的内存巧合，依赖：CanInterface() 偶然为 true、结构体可寻址、字段顺序未变、未启用 -gcflags="-l" 等多个脆弱前提。Go 1.21+ 已大幅收紧此行为，升级后立即失效。
- 检查字段是否导出的唯一可靠方式是：
t.Field(i).PkgPath == ""（空字符串表示导出） -
NumField()返回的字段数不包含私有字段，FieldByName()对私有名永远返回零值 - 试图对零值调用
.Interface()或.Addr()会 panic，但 panic 发生在你主动解包时，不是反射本身抛出的 error
reflect.ValueOf(x) 后调用 Set* 方法 panic 的根本原因
reflect.Value 默认是不可寻址的副本。传入 reflect.ValueOf(x) 得到的是 x 的拷贝，没有底层地址，因此 .CanSet() 为 false，任何 .Set* 都会 panic。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
要修改原值，必须传地址再解引用：reflect.ValueOf(&x).Elem()。但即使这样，也仅对可寻址变量有效：
- 字面量（如
reflect.ValueOf(&42)）不可寻址，.Elem()后仍不可 set - map value、struct 字段直取（未取地址）、函数返回值，均不可 set
- 即使
.CanAddr()为 true，也不代表.CanSet()为 true；后者还要求原始变量本身可寻址且非常量
为什么 recover 无法捕获反射相关的 panic？
recover 只能捕获当前 goroutine 当前调用栈上由 panic 主动触发的终止流程。而反射中多数 panic 是由非法操作直接引发的运行时崩溃（如对零值调用 .Interface()），不是通过 panic() 函数抛出的——这类 panic 不在 recover 的作用域内。
更关键的是：反射失败的典型路径根本不经过 panic。比如 FieldByName 静默返回零值，后续逻辑若没做 .IsValid() 检查就直接调用 .Interface()，panic 才发生，但此时已脱离反射上下文，属于你的业务代码越界访问。
-
defer func() { recover() }()对FieldByName返回零值毫无意义——它没 panic - 对
.Interface()的 panic 捕获，只是掩盖了本该在反射层就做的有效性校验 - 真正健壮的做法是：每次反射访问后立刻检查
.IsValid()和.CanInterface()，把问题拦在调用前
最容易被忽略的一点：当你花时间写反射逻辑去“绕过”私有字段限制时，其实已经走在错误方向上。Go 的封装边界是编译期硬约束，不是运行时可协商的配置项。替代方案从来不是“怎么捕获失败”，而是“如何让反射有合法入口”——导出字段、提供 accessor、用测试文件直访、走序列化协议。这些不是妥协，是与语言协作的基本前提。
