go中策略模式应简化为单方法函数值分发，避免接口+switch的冗余；策略只负责核心逻辑，剥离日志、错误处理等副作用；推荐字面量map或switch分发，依赖通过闭包注入，禁用运行时注册与共享状态。
为什么你的 if-else 链在 Go 里越来越难维护
Go 没有类继承和虚函数，硬套传统策略模式容易写成一堆接口+switch，反而更绕。真正卡住人的不是“怎么实现策略”，而是“策略边界划在哪”——比如该不该把 Error 处理、日志、重试逻辑塞进策略里？一旦混进去，每个策略就变成微型业务模块，替换成本飙升。
实操建议：
- 策略接口只暴露一个方法，比如
Execute(ctx context.Context, req *Request) (*Response, error)，拒绝任何副作用（不打日志、不发 metric、不 panic） - 把
if-else的判断逻辑单独抽成func(req *Request) String，返回策略名（如"payment_alipay"），别让它和策略实现耦合 - 避免用
map[string]Strategy做运行时注册——编译期没类型检查，新增策略时容易漏注册，直接用 switch 或查找表 + 单元测试覆盖分支更稳
用 map[string]func 实现轻量级策略分发
比起定义一堆 PaymentStrategy 接口实现，Go 更适合用函数值做策略载体。它天然满足“单一职责”，也规避了接口空实现、nil 指针 panic 等陷阱。
常见错误现象：panic: Interface conversion: interface {} is nil, not func(...) —— 因为 map 查不到 key 后直接调用了 nil 函数。
立即学习“go语言免费学习笔记（深入）”；
实操建议：
- 初始化策略映射时用字面量，别 runtime 注册：
var strategies = map[string]func(context.Context, *Request) (*Response, error){ "alipay": alipayHandler, "wechat": wechatHandler, "paypal": paypalHandler, } - 查策略必须带默认兜底：
handler, ok := strategies[req.PaymentMethod] if !ok { return nil, fmt.Errorf("unknown payment method: %s", req.PaymentMethod) } - 函数签名保持一致，参数别用
interface{}，否则类型安全全丢光
switch 比 map 更适合小规模策略分支
当策略少于 5 个，且分支逻辑差异大（比如有的要走 DB，有的纯内存计算），switch 反而更清晰。Go 的 switch 支持类型断言和多条件，比 map 查找还快，还省内存。
性能影响：10 万次调用下，switch 比 map[string]func 快约 15%，但差距微乎其微；真正拖慢的是策略内部 IO，不是分发层。
实操建议：
- 把
switch封装成独立函数，比如dispatchPaymentHandler(req *Request) (func(context.Context, *Request) (*Response, error), error)，别散落在业务逻辑里 - case 值必须是常量或 iota，别用变量，否则编译器无法做优化
- 每个 case 最后加
return，别靠 fallthrough——Go 不支持隐式穿透，写了也没用
策略间状态共享的坑：别传 *sync.Mutex 或 context.Context 进策略函数
看到“策略需要共享缓存”就往策略函数里塞 *redis.Client 或 *sql.DB？这是最典型的越界。策略只负责“做什么”，不负责“用什么资源做”。
容易踩的坑：多个策略共用同一个 *sync.Mutex，结果锁粒度错乱；或者把 context.WithTimeout 写死在策略里，导致上层超时控制失效。
实操建议：
- 依赖通过闭包注入，而不是参数传递：
func NewAlipayHandler(client *http.Client, cache *redis.Client) func(context.Context, *Request) (*Response, error) { return func(ctx context.Context, req *Request) (*Response, error) { // 使用 client 和 cache } } - 所有外部依赖（DB、HTTP、Cache）统一由工厂函数初始化，策略函数只接收纯净参数
-
context.Context必须由调用方传入，策略内部绝不调用context.WithXXX
策略最难的部分从来不是“怎么写”，而是“什么时候不该用”——比如校验规则、简单枚举转换、固定流程编排，硬套策略只会让代码更难读。留出一个明确的“非策略区”，比堆砌设计模式更重要。