调用 reflect.Value.Call 前必须检查可调用性：先验证 v.Kind() == reflect.Func 且 v.IsValid()，再考虑 v.CanInterface()；Field/Method 访问需校验索引范围与可访问性；reflect.ValueOf 后必先 IsValid() 再操作；Call 参数须严格匹配底层类型。
调用 reflect.Value.Call 前必须检查可调用性
Go 反射中，reflect.Value.Call 是最常触发 panic 的操作之一，错误信息通常是 panic: reflect: call of non-function 或 panic: reflect: Call using zero Value。根本原因是：传入的 reflect.Value 不是函数类型，或本身为零值（IsValid() == false）。
安全做法是显式校验：
- 先用
v.Kind() == reflect.Func判断是否为函数类型 - 再用
v.IsValid()确保非零值 - 最后用
v.CanInterface()（非必需，但有助于提前发现不可导出字段导致的调用失败）
if v.Kind() == reflect.Func && v.IsValid() {
results := v.Call([]reflect.Value{arg1, arg2})
// ...
} else {
return fmt.Errorf("not a valid callable value")
}
reflect.Value.Field 和 reflect.Value.Method 的越界与不可访问风险
通过 Field(i) 访问结构体字段、或 Method(i) 调用方法时，若索引超出范围，会直接 panic：panic: reflect: Field index out of bounds。更隐蔽的是：对未导出字段（小写开头）调用 Field(i) 返回的 reflect.Value 不可寻址、不可修改，后续调用 Set* 会 panic。
正确姿势：
- 用
v.NumField()/v.NumMethod()获取合法数量，再判断i - 用
v.Field(i).CanInterface()或v.Field(i).CanAddr()判断是否可安全读写 - 避免硬编码字段序号，优先用
v.FieldByName("Name")并检查返回值.IsValid()
field := v.FieldByName("ID")
if !field.IsValid() {
return fmt.Errorf("field 'ID' not found or unexported")
}
if !field.CanInterface() {
return fmt.Errorf("field 'ID' is unexported and cannot be accessed")
}
从 interface{} 到 reflect.Value 的零值陷阱
常见误写：reflect.ValueOf(nil).Elem() 或对空接口变量直接 reflect.ValueOf(x).Interface() 后断言，极易触发 panic: reflect: call of reflect.Value.Interface on zero Value。
将 WCAG 2 AA 无障碍标准应用于设计系统、UI 组件和网页——通过可运行的验证器进行对比度计算，采用设计 token 模式使颜色天生可访问，设定排版和焦点状态规则，并提供语义检查清单。适用于构建或审查 UI。
关键原则：任何由 reflect.ValueOf 得到的值，在调用 Interface()、Elem()、Index() 等方法前，必须先过 IsValid()。
-
nil指针、nilslice、nilmap 传入reflect.ValueOf后，得到的是有效Value，但其Kind()是指针/slice/map，Elem()或Len()可能 panic - 真正零值（如
reflect.Value{}）调用任何方法都 panic
v := reflect.ValueOf(ptr)
if !v.IsValid() {
return fmt.Errorf("value is invalid")
}
if v.Kind() == reflect.Ptr && v.IsNil() {
return fmt.Errorf("pointer is nil")
}
// 安全解引用
if v.Kind() == reflect.Ptr {
v = v.Elem()
if !v.IsValid() {
return fmt.Errorf("dereferenced value is invalid")
}
}
反射调用中参数类型不匹配的静默失败与 panic
reflect.Value.Call 对参数类型的检查非常严格：不仅要求 Kind 匹配（如 int vs int64），还要求底层类型一致。传入 reflect.ValueOf(int64(42)) 调用期望 int 参数的函数，会 panic：panic: reflect: Call using int64 as type int。
没有自动类型转换，也不能靠 Convert 强转所有类型（比如不能把 string 转成 int）。实际中建议：
- 用
reflect.TypeOf(fn).In(i)明确获取第 i 个参数期望的类型 - 用
arg.Convert(expectedType)尝试转换——仅当ConvertibleTo(expectedType)返回 true 时才安全 - 对基本类型做手动适配（如
int↔int64）比泛化反射更可控
反射不是万能胶，类型错配问题往往在运行时才暴露，越晚发现越难调试。
