Golang中如何设计一个支持条件判断的执行函数？策略模式【实战】

Go中用函数类型实现条件执行逻辑：定义func(status string) error类型，用map存储不同策略函数，调用前需判空；支持运行时参数时改用结构体传参，避免interface{}和过度抽象的接口，panic仅在goroutine中recover。

怎么用函数类型实现条件执行逻辑

Go 没有传统面向对象的“策略接口+多态调用”，但用 func() error 或带参数的函数类型就能快速封装不同行为。关键不是抽象出一堆接口，而是让调用方能按需传入具体逻辑。

比如需要根据 status 字段决定执行保存还是归档：

type Executer func(status string) error
<p>func saveHandler() error { /<em> ... </em>/ }
func archiveHandler() error { /<em> ... </em>/ }</p><p>var handlers = map[string]Executer{
"active":  saveHandler,
"archived": archiveHandler,
}

注意：handlers 中存的是函数值，不是函数调用结果；调用时要加括号：handlers["active"]()。

• 别把 func() error 和 func() (error) 当成等价写法——后者是语法错误，Go 不允许单个返回值加括号
• 如果 handler 需要访问上下文（如数据库连接），建议用闭包捕获，而不是硬编码全局变量
• map 查找失败会返回 nil 函数，直接调用会 panic，必须先判空：if h, ok := handlers[status]; ok { h() }

如何让策略支持运行时参数传递

纯无参函数太死板。多数真实场景需要传入 ID、配置或请求体。这时把函数签名改成 func(ctx context.Context, id string, cfg Config) error 更实用。

立即学习“go语言免费学习笔记（深入）”；

但要注意：不同策略可能需要的参数不一致。硬统一签名会导致某些策略接收一堆用不到的参数。更灵活的做法是定义一个结构体承载通用上下文，再让各策略按需解构：

type StrategyContext struct {
    ID     string
    DB     *sql.DB
    Logger *zap.Logger
    Config map[string]interface{}
}
<p>type Strategy func(StrategyContext) error

这样新增字段不影响旧策略，只要它们不读取新字段即可。

• 避免在 StrategyContext 里塞太多指针——容易引发并发读写冲突，尤其是 Logger 这类带状态的对象
• 如果某个策略只依赖 ID 和 DB，就别在调用时传入完整 Config，减少耦合
• 不要用 interface{} 做通用参数容器，它会让调用方完全失去类型检查

为什么不用 interface{} 实现策略抽象

有人会想定义 type Strategy interface { Execute() error }，然后让每个策略实现它。这看似规范，但实际带来三个问题：

• 每次新增策略都要写 struct + method，而多数策略只是几行逻辑，struct 定义纯属噪音
• interface{} 值传递会触发逃逸分析，小函数转成接口后可能分配堆内存
• 无法直接对函数做 map 查找，必须先包装成 struct 实例，增加间接层

除非策略本身需要携带状态（比如一个带计数器的限流策略），否则函数类型比 interface 更轻量、更直观。

真要用 interface，至少确保它只包含一个方法（符合 Go 的 “interface should have one method” 原则），且该方法签名与你最常调用的函数类型一致，例如：Execute(ctx context.Context) error。

panic 和 error 处理边界在哪

策略函数内部不应该 recover panic——那是上层编排逻辑的责任。所有策略都应以返回 error 为主流错误传达方式。

但有个例外：当策略函数被用作 goroutine 启动目标时，必须包裹 recover，否则 panic 会杀死整个 goroutine 且无迹可寻：

go func() {
    defer func() {
        if r := recover(); r != nil {
            log.Printf("strategy panicked: %v", r)
        }
    }()
    strategy(ctx)
}()

这个 recover 不是为“兜底容错”，而是防止未知 panic 导致任务静默失败。真正的业务错误（如 DB 连接失败）仍应走 return errors.New("...") 路径。

另外，别在策略里直接调用 log.Fatal 或 os.Exit——这会让整个进程退出，超出单个策略的职责范围。