Golang策略模式怎么设计_Golang策略模式实战案例

go中优先使用函数类型实现策略模式，如type LogFormatter func(String, map[string]Interface{}) string，因其简洁、无调用开销、测试友好；仅当需维护状态时才用结构体+方法。

用函数类型还是接口？Go里优先选func

Go 里策略模式最轻量、最常用的方式，不是定义一堆 type Strategy interface，而是直接用函数类型。比如日志格式化：type LogFormatter func(string, map[string]interface{}) string。它比接口更简洁、调用无开销、测试时直接传闭包就行。

• 纯算法逻辑（无状态、不依赖外部配置）——一律用 func 类型，别绕弯子写空结构体
• 需要维护状态（如限流器要记时间戳、重试器要存计数器）——才用结构体 + 方法，否则就是过度设计
• 接口只该描述“能做什么”，不是为了凑满一个“策略家族”而硬抽象；interface{} 更不行，它会让 strategy.Execute() 在运行时 panic

上下文怎么持有策略？避免 nil 和竞态

上下文（比如 PaymentContext 或 Order）通常持有一个策略字段，但直接裸写 strategy PaymentStrategy 容易出问题。

• 构造时必须检查是否为 nil，否则调用会 panic：在 NewXXX(strategy) 里加 if strategy == nil { panic("strategy cannot be nil") }
• 如果支持运行时热切换（比如根据用户等级动态换折扣策略），多个 goroutine 同时读写该字段会有竞态——得用 sync.RWMutex 保护，或干脆放弃可变，改用 WithStrategy() 返回新实例
• 别在上下文里 import 具体策略包（如 alipay），否则一加新策略就得改上下文代码，违背解耦原则

策略怎么注册和加载？别硬编码 switch

真实项目中，策略往往来自配置（YAML/jsON）或请求参数，而不是写死在代码里。靠 map[string]Strategy 查表是最常见做法。

• 把所有策略实例提前注册进全局 map：strategies["alipay"] = &Alipay{APIKey: cfg.Key}
• 用工厂函数封装加载逻辑：func NewStrategyFromConfig(name string) (PaymentStrategy, Error)，返回具体实例，而非类型名
• http API 场景下，可用请求头 X-Strategy: sha256 动态选策略，避免每个 handler 写 if 判断
• 注意：map 的 key 建议小写+下划线统一风格（如 "credit_card"），别混用驼峰或空格，否则配置易错且难调试

什么时候不该用策略模式？警惕伪解耦

策略模式不是银弹。当策略之间共享大量逻辑、或只有微小差异（比如仅差一个参数），强行拆成多个结构体反而增加认知负担。

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

• 两个折扣策略只差一个系数（0.1 vs 0.15）？直接用 FixedDiscount{Rate: 0.15} 结构体 + 字段就够了，不用搞三个独立类型
• 策略间需要频繁通信或共享缓存？说明它们本就属于同一责任域，可能该合并，而不是拆
• 新增策略频率极低（一年一次），且业务逻辑简单——if-else 更直白，别为模式而模式

真正值得上策略模式的，是那些你预见到未来半年内会新增两三种实现、且彼此完全正交的场景，比如支付渠道、日志后端、序列化格式。其他时候，先写清楚再重构。