go反射中reflect.value.set panic“unaddressable value”是因为值不可寻址，必须通过reflect.valueof(&x).elem()获取可寻址的原始变量，且字段需导出并满足canset()才可修改。
为什么 reflect.Value.Set 会 panic：“unaddressable value”？
因为 Go 的反射不允许修改“不可寻址”的值——它不是权限问题，而是内存模型限制。你传进去的如果是结构体值、字面量、interface{} 包装的值副本，或者 map 中直接取出来的元素，reflect.Value 底层就只是个只读快照，调 Set 必然 panic。
-
reflect.ValueOf(x)得到的是x的副本，不可寻址；必须用reflect.ValueOf(&x).Elem()才拿到可寻址的原始变量 - 即使字段名大写、类型匹配，只要没走指针路径，
CanSet()就恒为false - 常见误操作：
v := reflect.ValueOf(someStruct); v.FieldByName("Name").SetString(...)→ 直接 panic
怎么判断一个字段到底能不能改？只看 CanSet() 不够
CanSet() 是唯一权威判断依据，但它是个“结果型”方法：只有先确保可寻址 + 导出，它才可能返回 true。单独调它没意义，顺序错了就白查。
- 必须先做：
v := reflect.ValueOf(ptrToStruct).Elem()（否则CanSet()永远 false） - 再取字段：
field := v.FieldByName("Name")，注意：小写字段名如"name"会返回零值，且CanSet()为false - 最后检查：
if field.CanSet() { field.SetString("new") }—— 这一步不能省，泛型或动态字段名场景下漏判就是 runtime panic
修改 struct 字段时，嵌套、指针、interface{} 怎么处理？
嵌套结构体字段能改，前提是每一层都满足可寻址 + 导出；但 interface{} 或 nil 指针字段要额外小心，它们容易在 FieldByName 后突然变成不可设置状态。
- 嵌套字段：逐层
.FieldByName()，每一步都要检查CanSet()，比如v.FieldByName("Addr").FieldByName("City").CanSet() - 字段是
*string且为nil：不能直接SetString，得先reflect.New(field.Type.Elem()).Elem()创建新值，再赋给字段 - 字段是
interface{}：必须确认里面装的是可寻址值（比如*string），否则.Elem()后仍不可设；若装的是string值，则无法修改
哪些场景下反射改值是合理选择？
不是所有“想动态赋值”的地方都该上反射。它适合配置绑定、通用克隆、ORM 映射这类明确需要绕过编译期类型的场景，但代价是运行时开销和调试难度上升。
立即学习“go语言免费学习笔记（深入）”；
- 性能影响极小：单次
CanSet()几乎无开销，但反复反射访问字段比直接赋值慢 10–100 倍，高频路径慎用 - 兼容性稳定：Go 1.0 起这套规则就没变过，“可寻址 + 导出”是硬约束，不随版本松动
- 最容易被忽略的一点：你传进来的那个“东西”，到底是不是真实变量的地址？而不是某个函数返回的临时值、map 的
value、或者 interface{} 的底层副本——这点错，后面全错
