reflect.ValueOf(x).CanSet() 总是 false，因为传值导致获取的是不可寻址的副本；正确路径唯一：reflect.ValueOf(&x).Elem().CanSet() 为 true 需同时满足可寻址、字段导出、非 nil 且类型匹配。
reflect.ValueOf(x).CanSet() 为什么总是 false
因为 reflect.ValueOf(x) 拿到的是值副本，不是原始变量地址。Go 反射模型要求修改前必须可寻址，而传值进来就天然不可寻址。CanSet() 返回 false 是设计使然，不是 bug。
常见错误写法：reflect.ValueOf(someStruct).FieldByName("Name") —— 即使字段大写，CanSet() 也必为 false。
- 正确路径只有一条：
reflect.ValueOf(&x).Elem()，之后再FieldByName - 如果
x是结构体指针（如*User），直接reflect.ValueOf(x).Elem()即可，不用再取地址 - 对局部变量字面量（如
reflect.ValueOf(42)）或函数返回值，连&都加不了，反射根本无权改
结构体字段 CanSet() 为 false 的真实原因
即使走对了 & → Elem() 路径，字段仍可能 CanSet() 为 false。最常被忽略的是字段导出性：Go 强制规定只有首字母大写的导出字段才允许反射写入。
例如：type User { Name string; age int } 中，age 字段小写，FieldByName("age").CanSet() 一定返回 false，且自 Go 1.17 起无法绕过。
立即学习“go语言免费学习笔记（深入）”；
- 非导出字段不能靠
unsafe或同包 trick 修改——那是未定义行为，Go 1.21+ 已彻底失效 - 嵌套字段要逐层检查：
v.FieldByName("Profile").FieldByName("ID").CanSet()，中间任意一层失败，后续调用Set就 panic -
interface{}字段需先确认它装的是可寻址值（如*string），否则.Elem()会 panic
SetString / SetInt 等方法 panic 的典型场景
这类 panic 错误信息通常是 "reflect: reflect.Value.SetString using unaddressable value"，但真正原因往往藏在类型匹配或 nil 指针上。
- 对
*string字段，若值为nil，直接.Elem().SetString()会 panic；得先reflect.New(field.Type.Elem()).Elem()构造新值 -
int32字段误用SetInt(42)→ 必须用SetInt32(42)；Set方法不自动类型转换 -
map[string]int的某个 key 值不能直接MapIndex(key).SetInt()，因为 map 元素不可寻址；应替换整个 map 或用SetMapIndex - 切片元素同理：
slice.Index(i)得到的Value不可设，除非原切片本身是可寻址的指针
interface{} 和泛型结构体中反射赋值的坑
当你要处理 interface{} 参数（比如 ORM 解析 JSON patch、通用配置加载器），最容易漏掉 CanSet() 判断，导致 panic 时根本不知道哪个字段崩了。
例如：func SetField(obj interface{}, name, value string) error，若没提前校验 v.CanSet() 和 v.Kind() == reflect.String，一碰到私有字段或类型不匹配就 crash。
- 安全写法：每次
Set前都加if !v.CanSet() { return fmt.Errorf("field %s not settable", name) } - 对泛型结构体（如
type T struct{ Field any }），Field是any类型，但反射拿到的是底层具体类型，SetString不能直接用于any - 不要依赖“看起来能跑通”的测试用例——字段名拼错、包内小写字段、nil 指针、类型不一致，这些在单测里可能恰好没触发，上线后才暴露
真正难的不是写出能跑的反射代码，而是让每一步都带防御性检查：地址是否可寻址、字段是否导出、类型是否匹配、指针是否为 nil。少一个判断，就多一个生产环境 panic。
