在 Go 语言开发中，错误处理一直依赖显式的 error 返回值和层层判断。当我们需要把多个操作封装进闭包并统一捕获错误时，如果不用泛型，很容易写出接受 interface{} 的松散代码，导致运行时才暴露类型问题。通过定义明确的错误契约与高阶函数包装器，可以在编译期就保证闭包内错误类型的正确性。
为什么需要类型安全的错误捕获闭包
很多团队在 Go 1.18 以前就遇到了这类需求：把一组可能出错的动作丢进一个执行器里，执行器负责 recover 并记录错误。如果执行器签名写成 func(fn func() interface{}) error，那么传入的闭包可以返回任何东西，调用者根本不知道错误是不是被规范地传递出来。
这种写法的问题在于，业务方可能直接返回了自定义结构体却忘了包装成 error，执行器内部用类型断言取错误就会失败。类型安全的捕获闭包则是把“错误必须实现某个接口”这件事前置到函数参数类型上，由编译器帮我们卡住不合规的传入。
基于接口与高阶函数的实现方案
我们可以先定义一个业务错误接口，要求它除了内置 error 方法外，还带一个 Code 方法以便分类。然后提供一个 Wrap 函数，它接收严格签名的闭包，并返回可被执行器调用的统一类型。
下面代码展示了如何在不使用泛型的情况下，构造一个只接受返回 AppError 的闭包捕获器：
package main
import (
"fmt"
)
// AppError 是项目自定义错误接口
type AppError interface {
error
Code() int
}
// bizError 具体实现
type bizError struct {
msg string
code int
}
func (e *bizError) Error() string {
return e.msg
}
func (e *bizError) Code() int {
return e.code
}
// SafeClosure 类型安全的闭包类型，只能返回 AppError
type SafeClosure func() AppError
// Run 执行闭包并捕获错误
func Run(fn SafeClosure) AppError {
defer func() {
if r := recover(); r != nil {
fmt.Println("recovered:", r)
}
}()
return fn()
}
func main() {
task := func() AppError {
// 模拟业务出错
return &bizError{msg: "db fail", code: 500}
}
err := Run(SafeClosure(task))
if err != nil {
fmt.Println(err.Code(), err.Error())
}
}
在上面的例子中，SafeClosure 明确限定了闭包返回 AppError。如果你试图传入一个返回 string 或普通 error 的函数，编译器会直接报错，这就达到了类型安全的目的。
这种写法把“错误类型”绑定在了函数类型上，而不是靠运行时断言。执行器 Run 不需要知道具体业务错误结构，只要面向 AppError 编程即可，符合依赖倒置原则。
与泛型方案的对比
Go 1.18 之后可以用泛型写出 func Run[T error](fn func() T) T 的形式，看起来更灵活。但泛型方案在嵌套闭包或需要统一错误接口时，往往还要加约束比如 interface{ Error() string; Code() int }，写起来并不比显式接口简单。
非泛型的闭包包装器优势在于：对老版本 Go 友好，可读性高，IDE 跳转直观。缺点是每多一种错误分类就得定义对应闭包类型，不过实践中大多数项目错误接口是稳定的，所以维护成本很低。
| 维度 | 闭包接口方案 | 泛型方案 |
|---|---|---|
| Go 版本要求 | 1.0+ | 1.18+ |
| 编译期检查 | 强 | 强 |
| 多错误类型扩展 | 需新类型 | 自动适配 |
在任务调度中的落地示例
假设我们有一个定时任务系统，希望把任务注册为带错误分类的闭包，调度中心统一捕获并告警。借助前面的 SafeClosure，可以把任务池定义为 map[string]SafeClosure。
下面的片段演示了任务注册与执行的核心逻辑：
package main
import (
"fmt"
)
type AppError interface {
error
Code() int
}
type taskError struct {
msg string
code int
}
func (e *taskError) Error() string { return e.msg }
func (e *taskError) Code() int { return e.code }
type SafeClosure func() AppError
var tasks = map[string]SafeClosure{}
func register(name string, fn SafeClosure) {
tasks[name] = fn
}
func execute(name string) {
if fn, ok := tasks[name]; ok {
if err := fn(); err != nil {
fmt.Printf("task %s failed code=%d msg=%sn", name, err.Code(), err.Error())
}
}
}
func main() {
register("sync", func() AppError {
return &taskError{msg: "timeout", code: 504}
})
execute("sync")
}
这样，任何注册进来的任务都必须返回 AppError，调度代码完全不需要做类型判断。如果有人误写返回了普通 error，在 register 调用那一行就会编译失败。
从架构看，这种闭包契约让错误边界清晰：业务只管产出合规错误，平台只管消费合规错误，两边解耦且安全。
注意事项与常见误区
有人会把 SafeClosure 写成 func() error，然后在里面返回自定义结构，以为只要实现了 error 接口就安全。其实这丢失了 Code 方法的编译期约束，调用方拿到的 error 如果不断言就取不到业务码，又回到了运行时风险。
另一个误区是过度拆分错误接口。如果项目里出现五六个错误接口，闭包类型也会膨胀。建议先收敛成一到两个核心错误契约，再用包装函数做适配，保持闭包类型数量可控。
类型安全不是语法糖，而是把故障暴露在编译阶段的最低成本手段。
综合来看，在不能用泛型的场景或追求极致可读性的模块中，用接口加高阶函数实现错误捕获闭包，是一种务实且稳健的替代方案。