策略接口是定义行为契约的窄接口（如DiscountStrategy），必须用具体接口而非interface{}以保证编译期类型安全和可替换性。
什么是策略接口，为什么必须用 interface{}？
Go 没有传统面向对象的抽象类或虚函数，策略模式依赖的是接口契约。定义策略的核心是声明一个 Strategy 接口，它只包含行为方法（比如 Execute()），不关心实现细节。
常见错误是试图用结构体字段存具体类型，或者把策略硬编码成 *ConcreteStrategyA 这样的指针——这会破坏可替换性。正确做法是让所有策略实现同一接口，调用方只持有该接口变量。
- 接口定义要窄：只暴露策略必须提供的能力，例如
CalculateDiscount(price float64) float64 - 避免在接口里塞无关方法（如日志、初始化），否则违反单一职责
- 不要用
interface{}（空接口）代替策略接口——它失去类型约束，编译期无法检查是否实现了所需方法
如何动态切换策略而不改主逻辑？
关键在于把策略作为参数注入，而不是在业务代码里 if-else 判断后 new 一个具体类型。典型场景是支付方式选择、折扣计算、序列化格式切换等。
示例：一个订单服务支持多种折扣策略：
type DiscountStrategy interface {
Apply(amount float64) float64
}
type FlatRateStrategy struct{ rate float64 }
func (s FlatRateStrategy) Apply(amount float64) float64 {
return amount * s.rate
}
type ThresholdStrategy struct{ min, discount float64 }
func (s ThresholdStrategy) Apply(amount float64) float64 {
if amount >= s.min {
return amount - s.discount
}
return amount
}
// 主逻辑不感知具体策略
func ProcessOrder(total float64, strategy DiscountStrategy) float64 {
return strategy.Apply(total)
}
- 新增策略只需实现
DiscountStrategy，无需修改ProcessOrder - 策略实例可从配置、HTTP 头、数据库读取后构造，再传入
- 注意值接收 vs 指针接收：若策略含状态（如计数器），需用指针实现；纯函数式策略用值接收更安全
策略注册表怎么避免全局变量污染？
当策略种类多、来源分散（比如插件式加载），直接在 init() 里注册到全局 map 容易引发初始化顺序问题和测试困难。
推荐用依赖注入容器或显式注册函数，由启动逻辑统一管理：
var strategies = make(map[string]DiscountStrategy)func RegisterStrategy(name string, s DiscountStrategy) { strategies[name] = s }
func GetStrategy(name string) (DiscountStrategy, bool) { s, ok := strategies[name] return s, ok }
- 注册应发生在
main()或应用初始化阶段，而非包级变量初始化 - 测试时可清空
strategiesmap 或传入 mock 策略，避免跨测试污染 - 若策略需初始化（如连接 DB），不要在
RegisterStrategy里做重操作，而是延迟到首次Apply()时懒加载
为什么策略不能带 context.Context？
策略方法签名里混入 context.Context 是常见反模式。它会让简单计算逻辑被迫处理超时、取消等控制流，违背“策略只负责算法”的原则。
真正需要上下文的场景（如远程调用型策略），应该把 context 交给策略的执行环境，而不是塞进策略接口本身：
- 策略接口保持无副作用、无 IO、无 context —— 这样才能被安全缓存、并发复用
- 如果某策略内部要发 HTTP 请求，应封装为
RemoteDiscountStrategy，并在其Apply()内部自行处理 context（比如用ctx, cancel := context.WithTimeout(...)） - 主流程如
ProcessOrder若需整体超时，应在调用前控制，而不是让每个策略自己解析 context
策略模式的干净边界容易被“顺便加个日志”“顺手传个 config”这类需求悄悄腐蚀，越早明确它的职责边界，后期维护成本越低。
