reflect.Append需可寻址切片值，map须用SetMapIndex；扩容策略与原生一致，深拷贝须独立分配底层数组。
reflect.ValueOf 传入切片后，append 不起作用？
常见错误是：用 reflect.ValueOf 获取切片的 reflect.Value 后，直接对它调用 append —— 这根本行不通。append 是语言内置函数，只接受真实切片类型（如 []int），不接受 reflect.Value。
正确做法是用反射操作切片值本身：
- 确保该
reflect.Value是可寻址的（v.CanAddr()）、且是切片种类（v.Kind() == reflect.Slice） - 使用
v = reflect.Append(v, elem)，其中elem必须是同类型的reflect.Value - 如果要扩容底层数组，
reflect.Append会自动触发（类似原生append），但不会返回新地址——你得自己重新赋值给原变量或字段
示例：v := reflect.ValueOf(&s).Elem()（先取地址再解引用）才能获得可修改的切片反射值；若直接 reflect.ValueOf(s)，得到的是不可寻址的副本，Append 后的值无法回写。
map 类型无法用 reflect.Append，必须用 reflect.MapSetMapIndex
映射（map）没有“容量”概念，也不支持追加操作。Go 反射中没有 reflect.AppendMap 或类似函数——这是设计使然，不是遗漏。
立即学习“go语言免费学习笔记（深入）”；
向 reflect.Value 表示的 map 中插入键值对，唯一合法方式是：
- 确认
v.Kind() == reflect.Map且v.IsNil() == false - 键和值都需转为对应类型的
reflect.Value（例如reflect.ValueOf("k")和reflect.ValueOf(42)） - 调用
v.SetMapIndex(key, value)，注意 key 必须是可比较类型（如string、int），且不能是接口 nil
如果 map 是 nil，SetMapIndex 会 panic；必须先用 reflect.MakeMap 或 reflect.MakeMapWithSize 初始化。
扩容行为不受反射控制，完全由底层 runtime 决定
无论是切片还是 map，反射层只是暴露了操作入口，不干预其内存管理逻辑。也就是说：
-
reflect.Append触发的切片扩容策略，和原生append完全一致：小容量翻倍，大容量按 1.25 倍增长 -
reflect.MakeMapWithSize(n)的n仅是 hint，不是硬性桶数；实际分配可能略多或略少，且后续插入仍会自动扩容 - 反射无法获取当前 map 的 bucket 数量或负载因子，也无法强制预扩容到底层结构
所以别指望用反射“优化扩容时机”——该做的初始化（如 make([]T, 0, 100) 或 make(map[K]V, 100)）必须在反射之外完成，反射只负责运行时动态操作。
深拷贝切片/映射时，容易忽略底层数组共享问题
用反射实现通用拷贝工具时，若只递归复制元素，却不处理底层数组指针，就会复刻“幽灵数组”陷阱：
- 对切片做
reflect.Copy时，目标切片必须已分配独立底层数组（reflect.MakeSlice），否则仍共享源数组 - 对 map 做深拷贝，需遍历所有
v.MapKeys()，逐个SetMapIndex到新 map，不能只复制 map header - 嵌套结构体中的切片字段，若未显式
MakeSlice+Copy，反射拷贝后仍指向原底层数组
最易被忽略的一点：反射创建的新切片默认 len=0，但 cap 可能极小（如 0 或 1），导致后续多次 Append 触发频繁扩容——应在 MakeSlice 时就指定合理容量。
