策略接口必须用具体类型而非interface{}，以保障类型安全；动态注册推荐map[string]Strategy加sync.RWMutex；策略可调用外部服务但须依赖注入；生产环境优先发布更新而非热重载。
策略接口定义必须用 interface{} 还是具体类型？
Go 没有传统 OOP 的抽象类，策略模式的核心是定义一个统一的 Strategy 接口，所有具体策略都实现它。接口方法签名必须明确，不能用 interface{} 做参数或返回值来“灵活”，否则会失去类型安全和可维护性。
常见错误是把策略方法设计成 Execute(input interface{}) interface{}，导致调用方要反复断言、容易 panic。
- 推荐做法：根据业务输入输出确定具体类型，比如订单校验策略用
Validate(order *Order) error - 如果确实需要多态输入（如不同来源的原始数据），用泛型约束比
interface{}更安全（Go 1.18+） - 接口方法名保持语义清晰，避免
Do()、Run()这类模糊命名
如何动态注册和获取策略？用 map[string]Strategy 还是 sync.Map？
运行时切换策略依赖一个中心化的策略仓库。多数场景下直接用 map[string]Strategy + sync.RWMutex 就够用，比 sync.Map 更易测试、更可控。
典型错误是全局 map 未加锁，高并发下 panic 或读到零值。
立即学习“go语言免费学习笔记（深入）”；
- 注册策略时检查 key 是否已存在，避免静默覆盖
- 获取策略应返回
(Strategy, bool)，调用方必须判断ok，不能假设一定存在 - 不建议在
init()中自动扫描并注册策略——难以控制初始化顺序，也增加测试负担
var strategies = make(map[string]Strategy)
var strategyMu sync.RWMutex
func Register(name string, s Strategy) {
strategyMu.Lock()
defer strategyMu.Unlock()
if _, exists := strategies[name]; exists {
panic("duplicate strategy name: " + name)
}
strategies[name] = s
}
func GetStrategy(name string) (Strategy, bool) {
strategyMu.RLock()
defer strategyMu.RUnlock()
s, ok := strategies[name]
return s, ok
}
策略实现里能调用其他服务吗？比如数据库或 HTTP 客户端
可以，但必须通过依赖注入传入，不能在策略内部硬编码初始化客户端。否则策略无法单独单元测试，也违反单一职责。
常见反模式是策略里直接 new 一个 http.Client 或调用全局 DB 变量。
- 把外部依赖作为字段嵌入策略结构体，构造时传入
- 策略方法只负责编排逻辑，不负责资源生命周期管理
- 若策略需异步执行，明确返回
error而非启动 goroutine 后静默失败
type PaymentStrategy struct {
httpClient *http.Client
logger *log.Logger
}
func (p *PaymentStrategy) Process(ctx context.Context, req *PaymentRequest) error {
// 使用 p.httpClient 发起请求
// 使用 p.logger 打日志
return nil
}
切换策略时要不要做热重载？还是重启进程更稳妥？
绝大多数业务系统不需要热重载策略。策略变更本质是逻辑变更，不是配置微调。强行热加载会引入状态不一致、竞态、内存泄漏等复杂问题。
真正需要动态切换的场景，其实是「灰度发布」或「AB 测试」，这时应该用策略路由（Router），而不是替换策略实例本身。
- 策略本身应是无状态的；有状态的逻辑（如缓存、连接池）应由上层容器管理
- 如果必须运行时生效，用原子变量（
atomic.Value）替换整个策略实例，而非修改字段 - 生产环境优先走发布流程，策略变更触发一次滚动更新，比热加载更可靠
最常被忽略的一点：策略切换后，旧策略的 goroutine 可能还在运行，没做 context 取消或超时控制，会导致资源残留或结果错乱。
