策略模式替换if-else的核心是解耦条件判断与执行逻辑：判断只选策略，执行只干活，新增策略无需修改原有代码。
直接说结论：用策略模式替换 if-else，核心不是“写更多类”，而是把「条件判断」和「执行逻辑」彻底解耦——判断只负责选策略，执行只管干活，新增策略不用动老代码。
什么时候该用 Strategy 类而不是字典映射
当你的 if-else 分支里不只是调用一个函数，而是包含多行逻辑、状态维护、异常处理或需要复用实例时，Strategy 类比字典映射更合适。比如：
- 不同支付方式要各自初始化 SDK 客户端（微信需
WXPayClient，支付宝需AlipayClient） - 订单风控策略要共享缓存对象或数据库连接
- 某个策略内部需要重试、日志埋点、指标上报等横切逻辑
这时候用字典配函数会很快失控——函数闭包难管理、状态无法持久、复用成本高。而 Strategy 类天然支持属性、方法、生命周期控制。
Context 类要不要带 __init__ 参数
要看策略是否依赖运行时上下文数据。常见两种写法：
- 策略本身无状态，仅靠输入参数驱动 →
Context可不传参，策略通过execute()接收全部参数，如strategy.execute(order, user) - 策略需持有外部资源（如 DB session、配置对象）→ 在
Context.__init__里传入，再由Context.set_strategy(strategy)注入，避免每次调用都重复构造
别在 Context 构造时就硬编码策略类型，那又回到 if-else 原点了；真正切换策略的时机，应该在业务入口或工厂方法里做。
如何避免策略类爆炸导致 import 难维护
策略类多了以后，from .strategies import WechatPayStrategy, AlipayStrategy, CardStrategy 这种导入会越来越长。推荐两个实操做法：
- 把所有策略统一放在
strategies/__init__.py中显式导出：__all__ = ["WechatPayStrategy", "AlipayStrategy", ...]，上层只导入模块：from .strategies import *（注意仅限内部包） - 用字符串名 +
getattr动态加载，配合注册机制：STRATEGY_REGISTRY["wechat"] = WechatPayStrategy，这样新增策略只需注册，不改任何 import
后者更灵活，但要注意错误策略名会在运行时报 KeyError，建议在服务启动时校验注册表完整性。
为什么 execute() 方法参数不宜过载
看到有人把所有可能用到的字段都塞进 execute(self, **kwargs)，结果每个策略都要 kwargs.get("xxx", default)，这反而增加了理解成本。真实项目中应按策略职责收敛参数：
- 支付策略只接收
amount、order_id、notify_url - 折扣策略只接收
user、cart、coupon_code
如果某策略突然需要新字段，说明它职责已变，该拆不该加。参数膨胀往往是策略边界模糊的第一个信号。
策略模式真正的门槛不在语法，而在划分边界的直觉——哪些逻辑必须隔离，哪些可以共用，哪些该由上层兜底。一旦策略之间开始互相调用或共享私有字段，那就不是策略模式，是新的 if-else 借壳上市。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
