用@functools.total_ordering需同时定义__eq__和一个有序比较方法（如__lt__），否则报typeerror；它自动补全其余比较方法，但不处理父类已有逻辑，且__lt__是最推荐的核心方法。
直接说结论：用 @functools.total_ordering 能让你只写 __eq__ 和一个核心比较方法（比如 __lt__），其余 __le__、__gt__、__ge__ 会自动补全——但前提是必须定义 __eq__，否则会报错。
为什么 @total_ordering 会抛 TypeError: cannot generate total ordering
这是最常踩的坑：装饰器要求类至少实现 __eq__ 和「一个」有序比较方法（__lt__、__le__、__gt__ 或 __ge__ 中任一）。少定义任意一个，运行时就炸。
- 只写了
__lt__，没写__eq__→ 报错 - 写了
__eq__和__lt__→ 正常，__le__等自动推导为__lt__ or __eq__等逻辑组合 - 同时写了
__lt__和__le__→@total_ordering会忽略你手动写的__le__，仍按规则生成（可能和你预期不一致）
__lt__ 是最推荐实现的核心方法
因为语义清晰（“小于”是最自然的排序锚点），且和其他比较操作的推导逻辑最稳定。例如：
from functools import total_ordering
@total_ordering
class Score:
def __init__(self, value):
self.value = value
def __eq__(self, other):
return isinstance(other, Score) and self.value == other.value
def __lt__(self, other):
if not isinstance(other, Score):
return NotImplemented
return self.value
<p>这时 <code>Score(80) 、<code>Score(90) > Score(80)</code>、<code>Score(80) >= Score(80)</code> 全部可用，无需手写。</code></p>
- 返回
NotImplemented而不是抛异常，能让 Python 尝试反向调用（如other.__gt__(self)），提升类型混合比较的健壮性 - 如果业务上“相等”逻辑复杂（比如浮点容差、字段忽略 None），
__eq__必须自己精写，@total_ordering不干涉它
和手动实现全部比较方法相比，性能有影响吗？
几乎没有。所有自动生成的方法都是简单逻辑组合（例如 __ge__ 实际就是 not self ），没有额外对象创建或循环。但要注意：
- 如果你的
__lt__本身很重（比如涉及 IO 或复杂计算），那么__ge__等间接调用它时也会慢——这不是装饰器的问题，是设计问题 - Python 3.12+ 对
@total_ordering做了底层优化，生成函数直接内联，比早期版本更轻量 - 调试时别指望在栈里看到
__le__的源码行号——它根本没对应源码，是动态生成的函数对象
真正容易被忽略的是：当类继承自已有比较逻辑的父类时，@total_ordering 不会帮你合并父类的比较方法；如果父类已定义 __gt__，而你子类只加 __lt__ 和 __eq__，行为可能冲突。这种场景老老实实自己写全更稳妥。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
