反射赋值前必须检查 canset，否则必 panic；需确保值可寻址且可设置，如通过指针获取再 elem()，并避免对 map/slice 元素等不可寻址值直接设值。
反射赋值前必须检查 CanSet，否则必 panic
Go 反射里对 reflect.Value 调用 Set、SetInt 等方法时，如果底层值不可寻址或不可设置，会直接触发 panic：「reflect: reflect.Value.Set using unaddressable value」。这不是运行时偶然错误，而是设计约束——Go 不允许通过反射修改只读副本。
常见触发场景：
- 对普通变量字面量（如
reflect.ValueOf(42)）调用Set - 对结构体字段值（非指针接收）直接取
.Field(i)后尝试设值 - 从 map 或 slice 中取出来的元素值，默认不可寻址
正确做法是：先用 CanSet() 判断，且确保原始值来自指针：
type User struct{ Name string }
u := &User{}
v := reflect.ValueOf(u).Elem() // 必须 .Elem() 进入可寻址的 struct 值
if v.FieldByName("Name").CanSet() {
v.FieldByName("Name").SetString("Alice")
}
CanAddr 和 CanSet 不是一回事，别混用
CanAddr 表示该 reflect.Value 是否有内存地址（即是否由指针/取地址得到），而 CanSet 是更高一层权限：它隐含了 CanAddr 为 true，且不是不可变类型（如未导出字段、接口底层值等）。简单说：CanSet == true ⇒ CanAddr == true，但反过来不成立。
立即学习“go语言免费学习笔记（深入）”；
容易踩的坑：
- 对导出字段调用
CanAddr返回 true，但若原始对象不是指针（比如reflect.ValueOf(User{})），CanSet仍为 false - 对嵌套结构体字段，必须逐层确认可寻址性，
v.Field(0).Field(1).CanSet()前要确保v.Field(0)本身可寻址 - map 的
MapIndex、slice 的Index返回值永远CanAddr == false，不能直接设值
反射设值失败时，不要靠 recover 拦截 panic
用 defer/recover 捕获反射 panic 看似能兜底，但代价高、掩盖逻辑缺陷，且无法区分是误用反射还是其他深层错误。Go 反射的设值规则是确定的，完全可通过前置检查规避 panic。
实操建议：
- 所有可能设值的路径，统一加
if !v.CanSet() { return fmt.Errorf("cannot set field: %v", v.Kind()) } - 对用户传入的任意
interface{}，先用reflect.ValueOf(x).Kind() == reflect.Ptr判断是否为指针，再.Elem() - 设值前打印调试信息：
fmt.Printf("field %s: canAddr=%t, canSet=%t\n", name, v.CanAddr(), v.CanSet())
性能敏感场景下，避免在热路径反复反射
每次 reflect.ValueOf、FieldByName、MethodByName 都有明显开销，尤其在循环或高频调用中。即使加了 CanSet 检查，也无法抵消反射本身的成本。
更稳的做法：
- 提前缓存
reflect.Type和字段索引，比如用sync.Map存map[reflect.Type][]int表示字段路径 - 对固定结构体，生成静态 setter 函数（用
go:generate+stringer或自定义代码生成器） - 用
unsafe或go:linkname属于高风险操作，不推荐；优先选编译期可知的替代方案
真正难处理的，是那些字段名动态来自配置、且结构体类型又不固定的场景——这时 CanSet 检查只是底线，还得配合类型白名单和字段存在性验证，否则空指针或越界访问比 panic 更难查。
