reflect.len 对 map 报 panic 因其仅支持数组、切片、chan、String，map 需用 reflect.maplen；reflect.index 在索引越界时立即 panic，非延迟触发。
reflect.Len 为什么对 map 报 panic：invalid argument to reflect.Len
因为 reflect.Len 只支持数组、切片、chan、string —— 不支持 map。go 的反射设计里，map 的长度要用 reflect.Len 以外的方式获取，比如先用 reflect.kind 判断类型，再走 reflect.MapLen。
常见错误现象：panic: reflect: call of reflect.Value.Len on map Value
- 使用前务必检查
v.Kind() == reflect.Map，别直接套用Len() - 切片和数组能用
Len()，但 map 必须用MapLen()；两者返回值类型一致（int），但签名和语义不同 - 如果写通用遍历逻辑，建议统一用
switch v.Kind()分支处理，避免假设所有容器都支持Len()
reflect.Index 越界 panic 的真实触发点在哪里
reflect.Index 在索引超出 Value 实际长度时立即 panic，不是延迟到取值才报错。它本质是安全封装的下标访问，底层仍做边界检查。
典型误用场景：遍历切片时用 for i := 0; i （多跑一次）或未校验 <code>v.CanInterface() 就调 Index。
立即学习“go语言免费学习笔记（深入）”；
- 循环上限必须是
v.Len()，且用i ，不是 <code> -
reflect.Index要求目标Value是可寻址或可导出的；若源是 unexported 字段或 interface{} 包裹的私有结构体，可能 panic 或返回零值 - 性能上，
Index比原生切片访问慢一个数量级，高频场景别在热路径反复用
遍历嵌套切片时，如何避免 reflect.Value 重复解包出错
嵌套切片（如 [][]int）在反射中是一层 reflect.Slice 包着另一层 reflect.Slice，容易在递归时忘记重新判断 Kind 就直接调 Index，导致对非切片类型误用 Index。
常见错误现象：panic: reflect: call of reflect.Value.Index on int Value —— 说明你把某个元素当成了切片，其实它已经是基础类型了。
- 每次调
v.Index(i)后，必须重新检查v.Index(i).Kind()，不能依赖外层类型推断内层 - 如果要统一处理“容器类”类型（slice/array/map），建议用
if isContainer(v)辅助函数，内部用switch v.Kind()明确覆盖reflect.Slice、reflect.Array、reflect.Map - 注意
reflect.ValueOf(&x).Elem()和reflect.ValueOf(x)行为差异：前者可修改，后者只读；遍历时若需修改元素，得确保原始值可寻址
为什么 reflect.Value.Interface() 在遍历中常返回 nil 或 panic
因为 Interface() 要求 Value 是可导出的（exported），否则会 panic：“reflect.Value.Interface: cannot return value obtained from unexported field”。这不是 bug，是 Go 反射的安全限制。
典型场景：遍历结构体字段后拿到的 reflect.Value，其中某些字段是小写开头，调 Interface() 就崩。
- 不要无条件调
v.Interface()；先用v.CanInterface()判断是否允许转换 - 若只是打印或日志，可用
v.Kind().String()+v.String()组合兜底（v.String()对不可导出字段不会 panic） - 想安全提取值又不确定导出性？用类型 switch +
v.Int()/v.String()/v.Float()等方法，它们不依赖导出性，但只适用于基础类型
事情说清了就结束。反射本身不复杂，难的是每一步都要主动查 Kind、主动判 CanXXX、主动防越界——这些检查不是冗余，是 Go 把运行时风险提前暴露给你的接口设计。