functools.lru_cache 仅适用于纯函数，误用于含外部状态或可变默认参数的函数会导致错误；partial 解决参数固化问题，避免 Lambda 在循环中闭包陷阱；singledispatch 实现开闭原则的类型分发；total_ordering 需已明确定义 eq 和一个比较方法才安全。
为什么 functools.lru_cache 在服务中常被误用
它不是万能的缓存开关，而是有明确适用边界的轻量工具。真正值得缓存的，是纯函数、输入确定、计算开销大、调用频次高、且不依赖外部状态的逻辑。
常见错误现象：lru_cache 缓存了含 datetime.now() 或数据库查询的函数，结果永远返回旧值；或缓存了带可变默认参数（如 list）的函数，引发意外共享状态。
- 必须确保被装饰函数是纯的——同一输入永远返回同一输出
- 避免缓存实例方法（
self会作为第一个参数参与哈希），应改用@staticmethod或提取为模块级函数 -
maxsize=128是默认值，高频小参数场景可设为None（无限制），但要注意内存泄漏风险 - 调试时可用
my_func.cache_info()查看命中率，命中率长期低于 30% 就该怀疑是否真需要它
functools.partial 在回调和配置传递中的不可替代性
它解决的是“参数固化”问题，不是为了少打几个字，而是让接口更稳定、调用点更干净。典型场景是事件注册、异步任务提交、或统一日志前缀注入。
常见错误现象：用 lambda x: func(x, a=1, b=2) 替代 partial，导致闭包捕获变量延迟求值，在循环中出错；或把 partial 当成函数重命名工具，却忘了它不改变原函数的 __name__ 和 __doc__，影响调试和文档生成。
立即学习“Python免费学习笔记（深入）”；
- 在 for 循环中绑定回调时，必须用
partial(func, arg=val)，而非lambda: func(val) - 若需保留原函数元信息，加
@functools.wraps(func)包裹自定义包装器，partial本身不提供这个能力 - 注意
partial返回对象不是函数类型（是functools.partial实例），某些依赖inspect.isfunction()的框架会跳过它
为什么 functools.singledispatch 比 if/elif 更适合协议扩展
它不是语法糖，而是把“类型分发逻辑”从主流程里抽出来，让新增支持类型无需修改原有函数，符合开闭原则。工程中真正用起来，是在处理多种数据源解析、序列化适配、或策略路由时。
常见错误现象：给类方法注册 singledispatch，结果发现只对第一个参数生效，而方法隐含了 self；或注册了抽象基类（如 collections.abc.Sequence），却忘了子类不会自动匹配，必须显式注册或使用 register 的继承机制。
- 只能作用于第一个参数，所以设计函数签名时要把“要分发的类型”放在最左
- 注册具体类型（如
str、Path）比注册抽象类更可靠，后者需确认 MRO 和__mro__中是否包含目标 ABC - 调试时可用
my_dispatch.registry查看已注册类型，避免重复或遗漏 - 不支持异步函数，若需分发 async def，得自己实现类似逻辑或改用第三方库
functools.total_ordering 的边界和代价
它省的是代码量，不是思考量。只当你已经明确定义了 __eq__ 和某一个比较方法（如 __lt__）时才安全。强行套用，反而会让比较行为变得隐晦难测。
常见错误现象：只实现了 __le__ 就加 @total_ordering，结果 a 报 <code>TypeError；或在比较逻辑里混用了浮点数和近似相等（abs(a-b) ），导致 <code>__eq__ 和 __lt__ 之间矛盾，total_ordering 生成的其他方法直接失效。
- 必须实现
__eq__+ 至少一个其他比较方法（__lt__、__le__、__gt__、__ge__中任一） - 所有比较方法必须满足数学一致性：若
a == b and b ，则必须有 <code>a ，否则排序结果不可预测 - 性能上无额外开销，但它掩盖了比较逻辑的复杂度，多人协作时建议在 docstring 里写清全序依据
真正卡住人的，从来不是记不住 lru_cache 怎么写，而是没想清楚那个函数到底算不算“纯”；也不是不会用 partial，而是没意识到回调绑定时变量捕获的时机差异。这些地方不画出来，代码跑得再快，也会在某个上线后的深夜突然不对劲。