CanSet() 判断 reflect.Value 是否拥有对底层 Go 值的写权限，仅当返回 true 时才能安全调用 SetString()、SetInt() 等方法；返回 false 时强行调用会 panic。
CanSet() 判断的是“能不能写”，不是“该不该写”
CanSet() 只回答一个具体问题：当前这个 reflect.Value 是否拥有对底层 Go 值的**写权限**。返回 true 才能安全调用 SetString()、SetInt() 等方法；返回 false 时强行调用会 panic，且错误信息通常是 "reflect: reflect.Value.SetString using unaddressable value" 或类似表述。
它不关心变量本身在语法上是否“可变”（比如 const 或 let 风格限制），也不做类型兼容性检查——那是 SetXXX() 方法自己的事。
-
reflect.ValueOf(x).CanSet()恒为false：因为x是值传递，拿到的是副本，改了也没意义 -
reflect.ValueOf(&x).CanSet()也是false：这是指针本身的Value，指针变量不可被“设成另一个地址”（除非你真想改指针） - 正确路径只有一条：
reflect.ValueOf(&x).Elem().CanSet()→ 此时才指向原始变量本体
结构体字段修改前必须过三关：可寻址 + 导出 + CanSet()
即使你已用 &struct{} 入参并 .Elem()，字段仍可能不可设。常见卡点：
- 字段名小写（如
name）：反射中视为未导出，FieldByName("name")返回零值，CanSet()必为false - 嵌套结构体字段：需逐层
.FieldByName()，每一步都得检查CanSet()，比如v.FieldByName("User").FieldByName("Name").CanSet() - 字段是
*string且为nil：不能直接.Elem().SetString()，会 panic"call of reflect.Value.Elem on zero Value"；得先reflect.New(field.Type.Elem()).Elem()构造新值 - 字段是
interface{}：里面装的是string值？那不可设；装的是*string？得再.Elem()一次，并确认它可设
map/slice 元素不能直接 Set，得换思路
对 map[string]int 或 []int 的某个元素调用 Index(i) 或 MapIndex(key) 后得到的 reflect.Value，CanSet() 通常为 false。这不是 bug，是设计使然：Go 不允许通过反射原地修改 map/slice 底层数组中“未显式取地址”的元素。
立即学习“go语言免费学习笔记（深入）”；
- 修改 slice 单个元素：可用
value.Index(i).Set(...)—— 因为Index()返回的Value是可寻址的（文档明确说明） - 修改 map 单个 key 对应值：不能
MapIndex(key).Set(...)，必须用SetMapIndex(key, newValue) - 整体替换 slice/map：传指针 +
.Elem()，然后用Set()赋整个新值，例如v.Set(reflect.ValueOf(newSlice))
每次 Set 前加 CanSet() 判断不是可选项，是强制项
生产环境里漏掉这步，panic 往往发生在动态字段名、泛型结构或 interface{} 解包场景下，堆栈难定位。别依赖“我传了指针就一定行”——结构体字段私有化、中间 interface{} 包装、nil 指针字段、甚至 map 中存的是值而非指针，都会让 CanSet() 在某一层悄悄失败。
最稳妥的写法是：拿到字段 reflect.Value 后，立刻判断 if !field.CanSet() { return fmt.Errorf("field %s not settable", name) }。类型匹配、非空检查这些，都在 CanSet() 通过之后再做。
真正容易被忽略的，是那些“看起来能走通但其实不能设”的边界情况：比如 struct{ X *int } 中 X 字段本身可设（大写），但它指向的 *int 是 nil，此时 field.Elem().CanSet() 就不成立——而很多人只查了第一层。
