reflect.setlen修改切片长度的前提是：新长度不能超过原切片cap，且value必须可寻址（由指针解引用得到），否则panic。
reflect.SetLen 修改切片长度必须满足什么前提？
reflect.SetLen 不是万能的“扩容”工具，它只改 len，不碰底层数组内存。前提是：新长度不能超过原切片的 cap，否则 panic：reflect: call of reflect.Value.SetLen on slice with capacity 。
- 必须用
reflect.Value的可设置版本（即从指针解引用得到，且原变量本身可寻址） - 原切片不能是字面量或不可寻址值（比如直接传
[]int{1,2}给函数，再反射操作会失败） - 新长度可以小于等于当前
cap，但不能大于；想“真扩容”，得先用reflect.Append或手动reflect.MakeSlice+reflect.Copy
示例错误写法：
slice := []int{1, 2}
v := reflect.ValueOf(slice)
v.SetLen(5) // panic：cap 是 2，设成 5 越界
为什么 reflect.Value.Len() 和 reflect.Value.Cap() 返回值有时和预期不符？
因为 reflect.ValueOf 默认取的是值拷贝，不是地址。如果原始切片是局部变量、函数参数或 map 中的值，reflect.Value 可能无法反映后续修改，更关键的是——Cap() 在不可寻址的 Value 上返回的是 0（Go 1.17+ 行为变更）。
- 想正确读取
cap，必须确保Value可寻址：用&slice然后reflect.ValueOf(&slice).Elem() -
Len()在不可寻址时仍能返回正确值，但Cap()不行，这是容易被忽略的兼容性陷阱
常见误判场景：
func bad(s []int) {
v := reflect.ValueOf(s) // 不可寻址
fmt.Println(v.Cap()) // 输出 0，不是原切片 cap！
}
动态调整切片长度的可靠路径有哪些？
真要“动态改长”，得区分场景：是收缩（安全）、平移（需复制）、还是扩容（必须新建底层数组）。
- 收缩长度：直接
v.SetLen(n)，只要n 即可，无副作用 - 扩容到更大长度：不能靠
SetLen，得用reflect.Append（追加元素）或reflect.MakeSlice配合reflect.Copy - 想“清空但保留底层数组容量”：设
len为 0，而不是重新赋值nil，否则 GC 可能提前回收底层数组
安全扩容示例：
s := []int{1,2}
v := reflect.ValueOf(&s).Elem()
newV := reflect.Append(v, reflect.ValueOf(3), reflect.ValueOf(4))
s = newV.Interface().([]int) // s 现在是 []int{1,2,3,4}
reflect.SetLen 在 interface{} 参数里为什么总失败？
因为 interface{} 会做一次值拷贝，传入后 reflect.ValueOf(x) 得到的是不可寻址的副本，调用 SetLen 会 panic：reflect: reflect.Value.SetLen using unaddressable value。
立即学习“go语言免费学习笔记（深入）”；
- 解决办法只有两个：要么传指针（
*[]T），要么在调用前确保原变量可寻址（比如局部变量 + 取地址） - 别试图用
reflect.New包一层再复制回去——那只是改了副本，原变量没变
典型翻车现场：
func handle(i interface{}) {
v := reflect.ValueOf(i) // i 是 interface{}，v 不可寻址
v.SetLen(0) // panic！
}
真正能用的入口只能是：handle(&mySlice)，然后内部 reflect.ValueOf(i).Elem()。
实际用的时候，SetLen 几乎只出现在泛型不够用、又必须绕过编译期类型检查的极少数场景里。多数时候，该用切片表达式就用 s[:n]，该用 append 就用 append——反射不是语法糖，它是最后的逃生舱口，开舱前得确认氧气够不够。
