value.index 对固定长度数组索引越界会 panic：调用时若索引超出声明长度（如 [3]int 中索引 ≥3），反射层基于类型信息严格校验并直接 panic，而非运行时错误。
Value.Index 对固定长度数组索引越界会 panic
Go 反射中 Value.Index 用于访问数组或切片的第 n 个元素，但对固定长度数组（如 [3]int）调用时，若索引超出声明长度，会直接触发 panic：panic: reflect: slice index out of range。这不是运行时类型错误，而是反射层提前校验失败。
原因在于 Value.Index 内部调用的是 reflect.Value.unsafeAddr + 偏移计算，而固定数组的长度在类型信息里是硬编码的，反射会严格比对传入索引是否 Value.Len() —— 注意，这里不是看底层内存是否可读，而是看类型定义是否允许。
- 固定数组的
Len()返回声明长度（如[5]byte→ 5），不可变 - 切片的
Len()返回当前长度，Index也按此校验 - 即使你用
unsafe把数组转成更大切片，反射值仍是原数组类型，Len()不变
想安全访问数组任意偏移？别用 Value.Index，改用 unsafe.Slice
如果你确实需要绕过反射的长度限制（比如解析二进制协议、处理内存布局已知的结构体字段），Value.Index 不是解法。应该先拿到数组首地址，再用 unsafe.Slice 构造临时切片。
示例：有一个 [4]int，你想读第 6 个 int（假设内存后还有数据）：
立即学习“go语言免费学习笔记（深入）”；
arr := [4]int{10, 20, 30, 40}
v := reflect.ValueOf(arr)
ptr := v.UnsafeAddr() // 获取数组首字节地址
// 构造长度为 6 的切片（注意：仅当内存实际可读时才安全）
slice := unsafe.Slice((*int)(unsafe.Pointer(ptr)), 6)
// 现在 slice[5] 是可读的（但可能越界访问，需确保内存有效）
- 必须用
v.UnsafeAddr()，不能用v.Addr().UnsafeAddr()（后者对栈上小数组可能无效） -
unsafe.Slice不做边界检查，越界读写导致 undefined behavior - 该方式绕过了反射系统，后续不能再用
reflect.Value操作这个 slice
Value.Index 在循环中遍历数组时容易误用 len(v)
常见写法是 for i := 0; i ，看起来没问题。但要注意：如果 <code>v 实际是切片而非数组，v.Len() 是动态的；如果是数组，则固定。一旦你把一个切片赋给数组变量（如通过类型断言或接口转换），反射看到的仍是原类型。
- 错误场景：函数接收
interface{}，传入[]int{1,2,3}，但你在内部误以为它是[3]int并调用v.Index(3)→ panic - 正确做法：用
v.Kind() == reflect.Array或v.Kind() == reflect.Slice显式区分 - 更稳妥的遍历：统一转成切片再操作（
v = v.Slice(0, v.Len())），这样后续都走切片逻辑
数组转反射值后无法扩容，Index 不会自动适配新长度
固定长度数组一旦被 reflect.ValueOf 包装，其类型和长度就冻结了。哪怕你用 unsafe 修改了底层内存、甚至用 reflect.Copy 覆盖了更多字节，v.Len() 和 v.Index(n) 的行为仍只认原始类型长度。
- 没有“刷新”反射值长度的机制；
reflect包不提供修改Value类型信息的 API - 试图对
[2]int的反射值调用v.Index(2)，永远 panic，无论内存后面有没有数据 - 如果业务真需要动态长度访问，请从一开始使用切片，而不是靠反射“假装”它是数组
真正麻烦的地方在于：panic 发生在 Index 调用瞬间，没有提前预警机制，也难以在测试中覆盖所有索引路径。线上遇到这类 panic，往往意味着反射访问逻辑和实际数据布局存在隐式耦合，且这种耦合藏在类型声明里，不容易一眼看出。
