怎么用 reflect 看一个函数有没有 error 返回值
直接看函数类型签名的最后一个返回值是不是 error 接口类型。别试图调用它、别依赖文档注释，反射只认实际类型。
实操要点：
-
reflect.TypeOf(fn).Out(i)可以拿到第i个返回类型，.NumOut()先确认有几个返回值 - 判断是否为
error要用reflect.TypeOf((*error)(nil)).Elem()做基准比较，不能用字符串匹配或== - 注意：函数可能返回
*errors.errorString或自定义错误类型，只要实现了error接口就合法，但反射里只能看到具体类型，得用AssignableTo判断是否可赋值给error
func hasErrorReturn(fn interface{}) bool {
t := reflect.TypeOf(fn)
if t.Kind() != reflect.Func {
return false
}
n := t.NumOut()
if n == 0 {
return false
}
last := t.Out(n - 1)
errType := reflect.TypeOf((*error)(nil)).Elem()
return last.Implements(errType) || last.AssignableTo(errType)
}为什么签名校验函数通常要检查 error 返回
签名校验失败必须反馈错误，而不是静默忽略或 panic。否则上层无法区分「验签失败」和「网络超时」「参数缺失」等不同语义。
常见错误现象：
立即学习“go语言免费学习笔记（深入）”；
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 函数签名是
func([]byte, []byte) bool—— 返回bool意味着你丢掉了错误原因，调试时只能猜 - 返回
error但内部用fmt.Errorf("failed")泛化错误，没封装原始 crypto 错误（比如x509: certificate has expired） - 函数有多个返回值但
error不在最后，Go 社区惯例和errors.Is/As都默认最后一个是 error，工具链（如 gopls、staticcheck）也会据此告警
reflect.Value.Call 调用后怎么安全取 error
调用结果是 []reflect.Value，最后一个元素不一定是 error，得先判断类型再转，否则 .Interface().(error) 会 panic。
实操建议：
- 调用前先用上一节方法确认函数有
error返回，避免盲目取 - 取值后用
errVal.IsValid() && !errVal.IsNil()判断是否非空，再用errVal.Interface()转成接口 - 不要直接断言：
errVal.Interface().(error)—— 如果类型不是error，运行时 panic；应该先errVal.Type().Implements(errorType)
results := reflect.ValueOf(fn).Call(inArgs)
if len(results) > 0 {
last := results[len(results)-1]
if last.IsValid() && !last.IsNil() && last.Type().Implements(errorType) {
err := last.Interface().(error)
// 处理 err
}
}Golang 反射查 error 返回在签名校验中的真实限制
反射能告诉你「这个函数声明上有没有 error 返回」，但完全无法保证它「真的会返回有意义的错误」——比如空实现、永远返回 nil、或者 panic 替代错误返回。
容易被忽略的地方：
- 接口方法签名含
error，但具体实现可能没写（嵌入了未实现的匿名字段） - 函数是闭包或通过
func() interface{}包装过，反射看到的是包装后的类型，不是原始签名 - 交叉编译或 go:linkname 场景下，反射可能看不到导出符号的真实类型信息
签名校验这种强可靠性场景，反射只适合做预检或日志标记，核心错误路径必须靠单元测试覆盖真实分支。
