必须用 reflect.Value.len() 获取任意 slice 长度，但需先通过 reflect.ValueOf 转换并校验 kind() == reflect.Slice，否则 panic；len() 不支持 interface{} 因其编译期需具体类型。
用 reflect.Value.Len() 获取任意 slice 的长度
go 的 reflect 包是唯一能在运行时对未知类型 slice 获取长度的通用方式。关键不是“怎么取”，而是必须先确保传入的是 reflect.Value 类型且底层确实是 slice —— 否则调用 Len() 会 panic。
常见错误现象：panic: reflect: call of reflect.Value.Len on int value，说明你把非 slice 类型（比如 int、Struct）误传给了 reflect.Value.Len()。
- 必须先用
reflect.ValueOf(Interface{})转成reflect.Value - 必须检查
.Kind() == reflect.Slice，否则不能安全调用Len() - 如果原始变量是 nil slice（如
var s []String），Len()返回 0，不会 panic
func GetSliceLen(v interface{}) int { rv := reflect.ValueOf(v) if rv.Kind() != reflect.Slice { return -1 // 或 panic，按需处理 } return rv.Len() } s := []int{1, 2, 3} fmt.Println(GetSliceLen(s)) // 输出 3 fmt.Println(GetSliceLen("hello")) // 输出 -1（不是 slice）为什么不能直接用 len() 配合 interface{}？
len() 是编译期函数，只接受具体类型（如 []int、[]byte），不接受 interface{}。当你写 len(v) 且 v 类型是 interface{}，Go 编译器直接报错：invalid argument v (type interface {}) for len。
这不是语法限制，而是设计使然：Go 不允许在运行时对任意接口值做长度推导，因为底层数据结构可能根本没“长度”概念（比如 map、chan、struct）。
立即学习“go语言免费学习笔记（深入）”；
-
len()只支持数组、slice、string、map、channel —— 但必须是**已知具体类型**的值 -
interface{}擦除了所有类型信息，len()无从得知该调哪个底层实现 - 想绕过？只能靠
reflect手动还原类型并校验
reflect.SliceHeader 方式（不推荐，仅作了解）
有人会查到通过 unsafe + reflect.SliceHeader 直接读内存获取长度，例如：
func UnsafeSliceLen(s interface{}) int { sh := (*reflect.SliceHeader)(unsafe.pointer(&s)) return sh.Len }这完全不可靠 —— 因为 s 是 interface{}，其底层存储不是 SliceHeader 结构，而是 iface 结构（含 type 和 data 指针）。强行转换会导致读取错误内存，结果随机或 crash。
- 只有当参数是具体 slice 类型（如
[]int）时，unsafe.Pointer(&s)才指向有效的SliceHeader - 一旦换成
interface{}，地址语义失效，此法必错 - Go 1.17+ 对 iface 内存布局有调整，该方式彻底失去可移植性
实际项目中更建议的替代思路
反射虽能解决问题，但代价高、易出错。多数场景下，应优先考虑类型约束或接口抽象，而非硬上 reflect。
- 如果是自己定义的函数，用泛型（Go 1.18+）：
func Len[T ~[]E, E any](s T) int { return len(s) } - 如果必须处理多种 slice 类型，定义统一接口，让调用方显式适配：
type Sizer interface { Len() int } - 若对接外部动态数据（如 jsON 解析后不确定是 slice 还是 Array），先用
json.RawMessage延迟解析，再根据字段名/上下文判断是否转 slice
真正需要 reflect.Len() 的情况其实很少：通常是写通用工具库、序列化中间件或调试辅助函数。用之前，务必确认输入可控、类型可校验 —— 否则一个 nil interface 就会让服务 panic。