策略类必须实现统一接口，否则运行时抛错；应使用ABC定义抽象基类、初始化时检查方法存在性、单元测试覆盖；策略对象不可持业务状态，动态数据须通过execute()参数传入；推荐注册表模式管理策略；第三方依赖应由上下文注入而非策略内部硬编码。
策略类必须实现统一接口，否则 runtime 报错
Python 没有接口语法强制约束，但策略模式依赖「同一组方法签名」才能被上下文安全调用。如果某个策略类漏了 execute() 方法，或参数名不一致（比如一个用 data，另一个用 payload），运行时就会抛 AttributeError 或 TypeError。
实操建议：
- 用
ABC和@abstractmethod显式定义抽象基类，哪怕只是做文档和 IDE 提示 - 在上下文初始化时加一层检查：
hasattr(strategy, 'execute') and callable(getattr(strategy, 'execute')) - 单元测试里对每个策略实例调用
execute()，传空字典或默认值，验证不崩
策略对象不该持有业务状态，否则切换时出问题
常见错误是把用户 ID、订单号、缓存引用等塞进策略实例的 self.user_id 或 self.cache 里。一旦上下文复用该策略对象处理不同请求，状态就会串。
正确做法是把所有动态数据通过 execute() 参数传入：
立即学习“Python免费学习笔记（深入）”；
class DiscountStrategy:
def execute(self, order_amount: float, user_tier: str) -> float:
# 不读 self.user_tier，只读参数
if user_tier == "vip":
return order_amount * 0.9
return order_amount这样策略对象可安全地被多个线程/请求共享，也方便做依赖注入或工厂管理。
策略注册表用字典比 if-elif 链更易维护
当策略超过 3 个，硬编码 if strategy_type == "promo": return PromoStrategy() 很快失控。新增策略要改两处：类定义 + 分支逻辑。
推荐用注册表模式：
_STRATEGIES = {}
<p>def register_strategy(name):
def decorator(cls):
_STRATEGIES[name] = cls
return cls
return decorator</p><p>@register_strategy("cashback")
class CashbackStrategy:
...</p><h1>使用时</h1><p>strategy = _STRATEGIES.get("cashback")()好处：
- 新增策略只需加
@register_strategy("xxx")，不碰调度逻辑 - 策略列表可从配置文件加载（如 JSON 中的
"payment_strategy": "alipay"） - 运行时能用
_STRATEGIES.keys()做校验或调试输出
策略内部别直接调第三方 API，应由上下文注入 client
策略类里写 requests.post("https://api.xx.com/verify") 看似简单，但带来三个问题：无法 mock 测试、超时/重试逻辑重复、HTTP client 实例生命周期难管理。
应该把依赖显式传入：
class RiskCheckStrategy:
def __init__(self, http_client):
self.http_client = http_client # 如 requests.Session 或 httpx.AsyncClient
<pre class="brush:php;toolbar:false;"><pre class="brush:php;toolbar:false;">def execute(self, user_id):
resp = self.http_client.post("/risk", json={"uid": user_id})
return resp.json().get("pass", False)</code></pre>这样上层能统一配置 timeout、headers、mock client，也能按环境切换真实/沙箱 client。
真正容易被忽略的是策略组合场景——比如先走风控策略，再走折扣策略，两个策略都需要同一个 cache_client 实例。这时候靠构造函数注入比靠全局变量或单例更可控，也更容易做单元隔离。
