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——这会让整个进程退出，超出单个策略的职责范围。
