反射调用 func(...interface{}) 类型函数时 panic: wrong type for variadic argument
Go 反射调用变长参数函数最常卡在这儿：你把 []interface{} 直接塞进 reflect.Call()，结果报错 wrong type for variadic argument。这不是类型写错了，是反射不认“切片当可变参数”这个语法糖——它需要你手动拆包。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 别传
[]interface{}整体，得用...展开：把切片转成[]reflect.Value后，调用时写成fn.Call(args...) - 确保每个
reflect.Value都是目标函数参数所需的具体类型，比如原函数要string，你就不能只塞reflect.ValueOf("x")（它确实是string），但若原函数是func(...any)，那reflect.ValueOf("x")没问题；要是原函数是func(...int)，你就得用reflect.ValueOf(42)，且类型必须严格匹配 - 如果原始参数是混类型的（比如
"a", 123, true），又想统一走...interface{}，那就先构造成[]interface{}，再逐个转reflect.Value，最后展开
reflect.MakeFunc 包装变长函数时如何保留 ... 语义
你想用 reflect.MakeFunc 动态生成一个带变长参数的函数，但发现生成出来的函数不支持 f(1,2,3)，只能传一个切片？这是因为 MakeFunc 的签名里没显式写 ...，它只认固定参数列表。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 被包装的目标函数签名必须明确含
...T，比如func(int, ...string)，不能是func(int, []string) -
MakeFunc的第一个参数（即新函数类型）要用reflect.FuncOf构造，其中变长部分得用reflect.SliceOf(T)+true标记为 variadic，例如：reflect.FuncOf([]reflect.Type{intType, reflect.SliceOf(stringType)}, retType, true) - 在闭包体内，
in切片的最后一个元素才是变长部分，它本身是reflect.Value（类型为[]string），你要用.Len()和.Index(i)手动遍历，再传给真实函数
反射调用 fmt.Printf 这类标准库变参函数的实际限制
很多人试过用反射调 fmt.Printf，结果要么 panic，要么输出空或乱码。根本原因不是反射写错了，而是 fmt 内部做了大量类型特判和 unsafe 操作，绕过了反射能安全访问的边界。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 别反射调用
fmt.Printf、log.Printf等，它们不是普通函数，底层直接读栈帧或用unsafe解析参数，反射传过去的reflect.Value无法被识别 - 如果真要动态格式化，改用
fmt.Sprintf+ 字符串拼接，或者封装一层接受[]interface{}的 wrapper 函数再反射调用它 - 注意
fmt系列对nilslice、未导出字段、不支持的类型（如 func、map）行为不一致，反射传参时这些隐患会被放大
性能与类型安全：为什么生产代码里应尽量避免反射调变参函数
反射调变参函数不是不能用，而是代价比想象中高：每次调用都要做类型检查、值拷贝、切片分配、参数展开，还失去编译期类型校验。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 如果只是偶尔调用、参数结构固定（比如所有变参都是
string），优先用泛型函数替代，例如写func Do[T any](prefix string, args ...T) - 如果必须动态，把反射逻辑封在初始化阶段（比如 init 函数里构建好
reflect.Value缓存），而不是每次调用都reflect.ValueOf(fn) - 特别注意 GC 压力：
[]reflect.Value是堆分配，频繁创建会触发 GC；用sync.Pool缓存小切片能缓解，但别为了省几纳秒引入复杂度
变长参数 + 反射 = 类型系统让渡控制权。每多一层间接，就多一分 runtime panic 的可能，尤其是跨包、跨版本调用时，函数签名微调就足以让反射崩掉。
