Go中不用interface{}做策略抽象，因其丧失编译期类型检查和方法约束；应定义明确行为契约的接口（如PaymentStrategy），确保策略实现统一且调用安全。
为什么 Go 里不用 interface{} 做策略抽象
Go 没有传统 OOP 的抽象类或虚函数，但策略模式的核心是「运行时替换算法」。用 interface{} 虽然能接收任意类型，却失去编译期类型检查和方法约束，反而让策略行为变得不可靠。真正可行的是定义明确行为契约的接口，比如：
type PaymentStrategy interface {
Pay(amount float64) error
}所有策略实现都必须满足这个契约，调用方才能安全地切换逻辑。
如何避免策略注册时的循环依赖
常见错误是把策略实现（如 AlipayStrategy）和策略工厂（如 NewPaymentStrategy）放在同一包，又在 init() 中自动注册，结果导致 import 链断裂。推荐做法是显式注入，不依赖全局注册表：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 策略实例由业务层创建并传入上下文，例如
OrderService{strategy: &AlipayStrategy{}} - 若需动态选择，用 map[string]PaymentStrategy 显式初始化，而非反射或 init 函数
- 避免在策略实现文件中 import 工厂包，只依赖接口定义所在包
策略参数传递：该用 struct 还是函数选项模式
策略行为常需配置，比如支付超时、重试次数。直接在 Pay() 方法里塞一堆参数（Pay(amount, timeout, retry, certPath)）会快速失控。更稳健的做法是传入配置 struct：
type PayOption struct {
Timeout time.Duration
Retry int
Cert string
}
func (s *AlipayStrategy) Pay(amount float64, opt PayOption) error { ... }若后续扩展频繁，再升级为函数选项模式（functional options），但初期没必要——多数策略配置项稳定，struct 更直观、易测试、零分配开销。
并发场景下策略是否需要加锁
策略对象本身应是无状态的（stateless），即不保存请求间共享数据。如果策略内部缓存了 HTTP client、数据库连接池等可复用资源，这些资源本身已线程安全，策略无需额外加锁；但若误将用户 ID、订单号等请求级数据作为字段存进策略实例（如 s.userID = id），就会引发数据竞争。关键判断标准只有一个：策略实例能否被多个 goroutine 同时调用而不互相干扰。不能，就说明它不是真正的策略，而是带状态的工作单元——该拆成策略 + 上下文参数。
