根本原因是Go传值机制导致reflect.ValueOf(x)获得副本而不可寻址；必须传指针并调用.Elem()才能获得可设置的Value，且类型须完全匹配，slice/map需解引用两次，string仅支持整体替换。
传值还是传指针：CanSet() 为 false 的根本原因
直接对基本类型变量（如 int、string、float64）调用 reflect.ValueOf(x) 后尝试修改，一定会 panic —— 错误信息是 reflect: reflect.Value.SetInt using unaddressable value。这不是语法错，而是反射机制的硬性限制：CanSet() 返回 false。
原因很实在：Go 函数参数默认传值，reflect.ValueOf(x) 拿到的是 x 的副本，副本不可寻址，自然不可设值。必须传指针，让反射对象能“摸到”原始内存位置。
-
reflect.ValueOf(&x)得到的是*int类型的Value，CanSet()仍为false（它指向的是指针本身，不是目标值） - 必须链式调用
.Elem()：reflect.ValueOf(&x).Elem()才得到可寻址、可设置的int类型Value - 结构体字段同理：字段名必须大写（可导出），且必须从结构体指针出发，
reflect.ValueOf(&s).Elem().Field(0)
SetXxx 方法和 Set() 的类型匹配陷阱
即使 CanSet() 是 true，类型不匹配也会 panic。Go 反射不自动做类型转换，哪怕 int 和 int64 看起来只差一个字节。
常见错误包括：
立即学习“go语言免费学习笔记（深入）”；
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
- 对
int字段调用.SetInt(100)✅，但调用.SetFloat(100.0)❌（panic: call of reflect.Value.SetFloat on int Value） - 用
.Set(reflect.ValueOf(int64(100)))修改int字段 ❌（类型不一致，不是同一Kind） - 正确做法是确保源
Value和目标Value的Kind()和底层类型完全一致；必要时先用v.Convert(reflect.TypeOf(target).Type)（但需提前确认可转换）
slice 和 map 的“整体替换”必须解引用两次
很多人以为 reflect.ValueOf(&s).Elem() 就能直接改整个 slice，其实不行。slice 本身是 header 结构（包含 ptr/len/cap），要替换整个 slice，得把新 slice 赋给原变量地址所指的位置。
所以步骤是：
- 传入 slice 指针：
ptr := reflect.ValueOf(&s) - 取指针指向的 slice 值：
sliceVal := ptr.Elem()（此时sliceVal.CanSet() == true） - 构造新 slice 的
reflect.Value，比如newSlice := reflect.MakeSlice(reflect.SliceOf(reflect.TypeOf(0).Type), 3, 3) - 用
sliceVal.Set(newSlice)完成整体替换 - map 同理：必须
reflect.ValueOf(&m).Elem().Set(newMap)，不能对reflect.ValueOf(m)直接Set
字符串是只读的：无法用反射修改其底层字节数组
Go 中 string 是只读的底层字节数组 + 长度，语言层面禁止修改。反射也不能绕过这个约束 —— 即使你拿到 reflect.ValueOf(&s).Elem()，它的 CanSet() 是 false，所有 SetString 或 Set 都会 panic。
如果真需要“修改”字符串内容，唯一安全方式是赋新值：ptr.Elem().SetString("new") 是允许的（因为这是替换整个 string header），但注意这不会复用原内存，而是创建新字符串。
试图用 unsafe 强行修改底层字节属于未定义行为，生产环境绝对避免。
