可变参数函数在反射中无特殊处理，...t等价于[]t，但调用时需将每个实参单独转为reflect.value；rows.scan要求每个interface{}为指针，故须手动构造指针切片并逐个包装；reflect.makefunc回调固定接收[]reflect.value，需手动提取可变部分并转换类型；常见panic包括参数数量不足、类型错误及零值调用。
可变参数函数在反射调用中不会被特殊对待 —— 它的 ...T 参数在反射层完全等价于普通切片 []T，但你传参时仍需把每个实参单独包装为 reflect.Value，不能把整个切片当一个参数塞进去。
为什么 Rows.Scan 的反射调用必须手动构造指针切片
database/sql.Rows.Scan 声明为 func(...interface{}) error，表面是可变参数，实际签名等价于 func([]interface{}) error。但关键在于：它要求每个 interface{} 实际指向一个变量地址（即 *T），否则会报 sql: Scan error on column index 0: destination not a pointer。
- 直接传
reflect.ValueOf([]interface{}{&a, &b})是错的 —— 这只传了一个切片参数，而Scan期望的是多个独立的interface{}参数 - 正确做法是先建一个
[]interface{}存值，再建一个同长的[]interface{}存对应指针，最后把每个指针转成reflect.Value构成参数切片 - 例如：对两个
int变量a,b，参数切片应为[]reflect.Value{reflect.ValueOf(&a), reflect.ValueOf(&b)}
reflect.MakeFunc 处理可变参数函数时的回调签名陷阱
无论原始函数是否带 ...，reflect.MakeFunc 的回调函数签名固定为 func([]reflect.Value) []reflect.Value。你不能假设 in 里某个元素是“整个可变参数切片”；它只是按调用时传入的实参个数，逐个展开的 reflect.Value 列表。
- 若目标函数是
func(string, ...int)，且你调用f("x", 1, 2, 3)，则in长度为 4：in[0]是"x"，in[1]~in[3]是三个int值 - 想还原为
[]int，得手动提取in[1:]并逐个调用.Int()转基础类型，再构造成切片 - 别试图对
in[1]直接调.Interface().([]int)—— 它只是单个int的reflect.Value，不是切片
用 reflect.Call 调用可变参数函数时最常 panic 的三个原因
反射调用可变参数函数本身不增加额外复杂度，但因参数组织方式更易出错，以下三点高频触发 panic：
-
reflect: Call using too few arguments：误把...T当作一个参数传，比如对fmt.Printf调用时传了[]reflect.Value{reflect.ValueOf("hello %d"), reflect.ValueOf([]interface{}{42})}（后一项是切片，应拆成两个元素） -
wrong type for parameter N：未校验参数类型，例如目标函数要*string，却传了reflect.ValueOf("hello")（缺少取地址） -
call of reflect.Value.Call on zero Value：没检查reflect.ValueOf(fn).IsValid()就直接调用，常见于从 map 或 interface{} 解包后未判空
真正容易被忽略的是：可变参数函数的“动态性”全在调用方，反射层没有任何语法糖或自动解包 —— 你传什么，in 就是什么；你少传一个，就少一个；你类型错一个，就崩一个。所有“智能”都得自己写逻辑兜住。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
