高阶函数可替代策略模式，将策略逻辑封装为独立函数并作为参数传递，适用于无状态、简单场景；需统一参数签名、避免self错误、用闭包预置参数，有状态时应回归类实现。
高阶函数怎么替代策略类
策略模式传统写法是定义抽象基类，再派生多个具体策略类。用高阶函数实现，核心是把策略逻辑封装成独立函数，再把函数本身作为参数传给上下文——函数即策略，无需类结构。
这样做不是为了炫技，而是当策略逻辑简单、无状态、不需复用实例属性时，能省掉模板代码。
常见错误是强行把带 self 的方法塞进高阶函数调用链，结果报 TypeError: missing 1 required positional argument: 'self'。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 每个策略函数应接收相同签名的参数（例如都接受
data和可选**kwargs），便于统一调度 - 避免在策略函数内修改外部变量；如有配置依赖，通过闭包或
functools.partial预置参数，而不是靠类属性 - 若策略需要维护内部状态（如计数器、缓存），高阶函数方式会很快变得难维护——这时该回归类实现
functools.singledispatch 能不能当策略分发器
可以，但要小心它的设计边界：singledispatch 是按第一个参数的类型分发，本质是“单参数类型驱动”的策略路由，不是通用策略容器。
比如你有一组处理不同数据格式的函数：process_json()、process_csv()、process_xml()，用它很自然；但若策略选择依据是业务规则（如 user.tier == 'premium' 或 order.amount > 1000），它就完全不适用。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 只在策略分支明确由输入类型决定时使用
@singledispatch，否则用普通字典映射更直接 - 注册函数时别漏掉
@<code>singledispatch.register 装饰器，否则运行时不会被识别 - 不要试图用它绕过类型检查：mypy 对
singledispatch的支持有限，过度使用会让类型提示失效
如何安全地动态切换策略函数
策略函数常需要运行时根据配置或用户输入切换，最简方式是用字典做映射表，键为策略标识，值为函数对象。
容易踩的坑是把字符串名直接 eval() 或 getattr() 到模块里调用——这带来执行风险和调试困难。
另一个问题是函数被意外覆盖或未定义，导致调用时报 KeyError 或 NameError。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 预定义策略字典，初始化时校验所有值是否为可调用对象：
assert callable(func) - 用
dict.get('strategy_name', default_func)提供兜底，而不是直接下标访问 - 策略函数名不要和内置函数同名（如叫
filter、sum），否则可能遮蔽原生函数且难以排查 - 如果策略来自配置文件（如 JSON/YAML），只允许白名单内的键映射到预设函数，禁止任意代码执行
性能差异：函数 vs 类策略对象
纯函数策略在创建开销上远小于类实例，没有 __init__、没有 __dict__、没有虚函数查找——这对高频调用场景（如每秒数千次的数据清洗）有意义。
但反过来说，如果策略函数内部反复做相同初始化（如打开文件、连接数据库、编译正则），反而比类策略更慢，因为类可以把这些提到 __init__ 里只做一次。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 用
timeit实测关键路径，别凭直觉判断“函数一定更快” - 若策略需复用资源（如 HTTP session、SQLAlchemy engine），必须用类封装生命周期，函数只能负责“使用”，不能负责“管理”
- CPython 下函数调用本身几乎无额外开销，瓶颈通常在策略体内部，而非调度方式
真正难的不是把策略写成函数，而是判断哪些状态该外提、哪些规则该固化、哪些分支该保留运行时灵活性——这些决策不会因为用了高阶函数就自动变简单。
