企业官网建设流程全解析

1. 从“为什么需要”说起：运算逻辑不该是函数的一堆剪不断理还乱的调用

我第一次意识到运算符重载的价值，是在写一个三维向量库的时候。那会儿刚工作不久，心气高，觉得自己能把所有东西都用函数搞定。结果就写出来addVectors(scaleVector(v1, 2.0), v2)这种嵌套调用，一个表达式三层括号，读代码的人要花十秒钟才能弄清楚到底先做哪个运算。后来我把Vector类重载了+、*，同一个表达式写成v1 * 2.0 + v2，一行代码，语义清清楚楚，同事看完直呼“这才像数学”。

这就是运算符重载的核心价值：让自定义类型的行为模式和内置类型保持一致。内置的int、float、string可以用+、-、*、==做运算，我们的自定义类型为什么不行？运算符重载本质上是一种语法糖，它不改变语言的底层能力，但它把“函数调用”这件机器思维的事情，翻译成了“数学表达”这种人类直觉。

不过这里有个关键前提：运算符重载不是让你随便玩的。它有一套语言的底层约定，有坑，有陷阱，有“看着能跑但逻辑全错”的危险操作。这篇文章我结合这些年用 Python 和 C++ 写库、写业务代码的实操经验，把运算符重载的设计思路、核心场景、实现要点、排查技巧一次说透。适合三类人看：封装数据结构的库开发者、写领域模型（金额、日期、坐标、矩阵这些）的业务程序员、以及想在面试里把这个话题聊出深度的人。

语言上我以 Python 为主，因为它的数据模型对运算符重载的支持最直观、最完整，同时补充 C++ 的对照写法。两种语言的思路完全打通之后，其他语言（Rust、Swift、Kotlin）基本都是同一套逻辑换层皮。

2. 运算符重载的底层逻辑与设计原则

2.1 重载的本质：拦截运算并绑定到方法

先说底层原理。当你写a + b的时候，语言内部做的事情不是“直接相加”，而是经历了一次查找与分派。Python 里，解释器会优先调用a.__add__(b)，如果a没实现或者返回了NotImplemented，再尝试b.__radd__(a)。C++ 里则是在编译期根据操作数的静态类型去查找重载的operator+函数。

这意味着什么？运算符重载的本质是“拦截”——你拦截了语言内置的运算符号，把它绑定到你自己的方法实现上。这个机制决定了三件事：

第一，运算的语义完全由你定义。你可以让+做拼接、做合并、做坐标叠加，甚至做集合交集（虽然我不建议这么干），语言层面不会拦你。这既是自由，也是责任。

第二，有对应的“反运算”方法。Python 里a + b和b + a可能走完全不同的代码路径，因为前者走__add__，后者可能走__radd__。很多新手写的类只实现了__add__，结果2 + obj直接报错——这就是没处理反向运算的典型问题。

第三，运算符重载和函数重载有个根本区别：运算符重载不仅仅是“名字相同参数不同”，它还在改变表达式本身的“语法外观”。a + b在视觉上就是一个加法表达式，读者会下意识用加法（数学运算）的直觉去理解它。所以，重载后的行为必须符合人们对这个符号的普遍直觉。这是整篇文章最重要的一条原则。

2.2 必须遵守的三大设计铁律

我踩过不少坑，也 review 过别人不少代码，总结出三条铁律，可以说适用于所有支持运算符重载的语言：

铁律一：语义必须符合直觉。+就是合并、叠加、拼接；*就是重复、缩放、交叉组合；==就是“这两个对象在业务上是同一个东西”。你不能让+做减法逻辑，也不能让==返回“相似度 0.8”这种模糊概念。运算符不是函数名，你可以在函数里随便叫merge然后内部做减法，但你不能让+做减法——因为读代码的人会用数学直觉去理解那一行表达式，一旦直觉被违背，代码的可维护性直接崩盘。

铁律二：运算结果要返回新对象，不要修改自身。这一点 Python 和 C++ 的传统不太一样。C++ 的operator+=通常修改自身并返回引用，但operator+必须返回新对象。Python 的__add__同样应该返回新对象，而__iadd__才允许原地修改。很多新手把__add__写成“把对方的值加到自己身上然后 return self”，结果a + b执行完，a的值居然变了。这在语义上是灾难——a + b在所有人的直觉里都是一个“不改变操作数”的纯运算。

铁律三：重载集合必须成套。实现了==就必须实现!=；实现了<最好把>、<=、>=一起实现；Python 里实现了__eq__，__hash__也必须同步处理，否则对象放进集合或字典里会出诡异问题。原因是：这些运算符在语言层面存在等价转换关系。a != b在 Python 里会先尝试a.__ne__(b)，如果没有则取not a == b的结果；C++ 里a > b如果没有重载operator>，编译器不会自动转换成b < a。成套实现，才能保证逻辑一致性。

另外还有一个容易被忽略的点：保持可交换性的一致性。如果a + b和b + a在你的业务语义里应该是相等的（比如向量加法），那两条路径都要实现，并且结果要一致；如果本来就不相等（比如字符串拼接），那就要明确这个类型是“非对称运算”，并确保文档写清楚。对称性问题我们在后面的排查章节详细展开。

3. 核心应用场景：哪些自定义类型最需要运算符重载

3.1 数值与向量类型：数学表达的直接映射

最经典、也最适合用运算符重载的场景，就是数值计算相关的自定义类型。三维向量、复数、矩阵、分数、颜色值（RGBA 的加法混合）、坐标点，这些类型的业务本质就是“数学对象”，它们的运算天然对应+、-、*、/。

以二维向量为例，核心操作就四个：向量加法、向量减法、标量乘法、点积（或者用@）。用 Python 实现：

class Vector2D: def __init__(self, x, y): self.x = x self.y = y def __add__(self, other): if not isinstance(other, Vector2D): return NotImplemented return Vector2D(self.x + other.x, self.y + other.y) def __sub__(self, other): if not isinstance(other, Vector2D): return NotImplemented return Vector2D(self.x - other.x, self.y - other.y) def __mul__(self, scalar): # 标量乘法：向量 * 数字 if not isinstance(scalar, (int, float)): return NotImplemented return Vector2D(self.x * scalar, self.y * scalar) def __rmul__(self, scalar): # 反向标量乘法：数字 * 向量 return self.__mul__(scalar) def __repr__(self): return f"Vector2D({self.x}, {self.y})"

这里有个细节值得注意：__mul__里我判断了isinstance(scalar, (int, float))，如果不是数字就返回NotImplemented。这个NotImplemented是 Python 里的一个特殊单例，意思是“我不会处理这种类型的操作数”，解释器收到它之后会尝试对方的反向方法。这样处理之后，vec * 2走__mul__，2 * vec走__rmul__，两边都能正确运行。

C++ 的实现思路一样，但有个语法层面的选择：用成员函数还是友元函数。我个人的习惯是：需要隐式转换的场景，用友元函数。比如标量乘法2.0 * vec，如果operator*是 vec 的成员函数，2.0无法匹配，编译直接失败；但如果定义成友元函数friend Vector2D operator*(double s, const Vector2D& v)，就支持了左操作数为标量的写法。

class Vector2D { public: double x, y; Vector2D(double x_, double y_) : x(x_), y(y_) {} Vector2D operator+(const Vector2D& other) const { return Vector2D(x + other.x, y + other.y); } friend Vector2D operator*(double s, const Vector2D& v) { return Vector2D(v.x * s, v.y * s); } Vector2D operator*(double s) const { return Vector2D(x * s, y * s); } };

数值类型还有一个进阶设计：实现混合运算。比如“分数 + 整数”Fraction(1, 2) + 1应该等于Fraction(3, 2)，这需要__add__里判断isinstance(other, int)并做转换。很多库的实数类型（比如decimal.Decimal）都是这么做的——先尝试把操作数转换成自己能处理的类型，再执行运算。转换失败再返回NotImplemented，把机会让给对方。

3.2 领域模型对象：让业务代码像业务文档

第二个高频场景是领域模型。金额（带币种）、日期区间、订单号、JSON 节点，这些类型的运算不像向量那么“数学”，但重载运算符能让业务代码的阅读成本大幅降低。

举一个最典型的例子：Money类型。如果每次金额相加都要写money1.add(money2)，代码很快就变成一团乱麻；但如果实现了__add__、__sub__、__mul__，业务代码就能写成total = subtotal + tax - discount，一眼过去就是一条清晰的账目流水。

这里有一个值得展开的设计点：币种不一致怎么办？严谨的做法是在__add__里检查币种，不一致就抛异常；宽松的做法是自动换算。我建议前者——因为在财务场景里，把 USD 和 CNY 直接相加的后果远比抛一个异常严重。这就是运算符重载的“领域守则”：重载的不仅是运算，还是业务规则的执行点。

日期区间也很典型。Period类型重载<和>之后，就可以写if (start_date < period.start)来判断一个日期是否早于区间的起始点；重载&表示交集、|表示并集之后，复杂的区间逻辑可以用一个表达式解决。Python 的dateutil.rrule以及很多时间处理库都在做类似的事。

做领域模型的重载时，有两点经验供参考：

第一，返回值类型要克制。Money + Money返回Money，没问题；Money * 0.1返回Money，也没问题（前提是处理好转货）；但Money / Money返回什么？Money不对，应该是Decimal（倍数）。如果你的__truediv__强行返回Money，语义就崩了。所以重载__truediv__时要先想清楚：这个运算结果的“类型”到底是什么，不要想当然。

第二，比较运算要定义“排序键”。Python 3 里实现__lt__最省事的方式是直接比较一个可排序的内部属性：

class Money: def __lt__(self, other): if not isinstance(other, Money): return NotImplemented if self.currency != other.currency: raise ValueError(f"cannot compare {self.currency} with {other.currency}") return self.amount < other.amount

Python 的functools.total_ordering装饰器可以基于__lt__和__eq__自动补充其他比较运算。用的时候加一行@total_ordering，然后只实现这两个方法，语言自动生成<=、>、>=。但 C++ 没有这个语法糖，std::rel_ops也已经在 C++20 被废弃，所以我建议 C++ 里直接用三路比较operator<=>（C++20 飞船运算符），一个方法自动生成全部比较运算。这个细节后面实操部分再说。

3.3 容器与集合类型：拼接合并的自然表达

第三种高频场景是实现自定义容器。你封装了一个双向链表、一个前缀树、一个有序集合，天然希望它支持+做拼接、[]做索引、in做成员判断。

Python 里这组协议叫“容器协议”：__len__、__getitem__、__setitem__、__contains__、__iter__。实现之后，你的自定义容器用起来和内置的list、dict几乎没差别。C++ 里同样，重载operator[]让自定义容器支持下标访问，重载operator<<让容器可以直接输出到流。

我做过一个“支持事务回滚的列表”类型，内部用list存储，但每次操作记录 undo 日志。重载__getitem__、__setitem__、__len__之后，外部调用方完全感知不到它是“有事务的”，代码像操作普通列表一样自然。这就是运算符重载对抽象边界的价值——它封装了差异，暴露了共性。

容器的重载要注意一个细节：+的语义。两个容器相加，到底是“拼接成一个新容器”还是“合并元素”？这要看容器类型。列表是拼接，集合是并集。如果你做的是一个自研集合类，+应该语义等同于“并集”吗？我建议：能用|表达并集、用&表达交集的语言，就不要让+承担并集的语义。Python 里set就是|和&，list才是+拼接。让每个符号只承担一种语义，这个原则能避免使用者踩坑。

另一个细节是in运算符。实现__contains__之后，element in container这个判断的复杂度取决于你的实现方式。前缀树里实现__contains__时我用了从根节点逐层遍历的逻辑，复杂度 O(m)（m 是查询串长度），比把整个树 flat 成列表再线性查找快了一个数量级。运算符重载不只是“语法好看”，它还是性能优化的入口——因为你拦截了运算本身，可以在方法内部选择最优的实现路径。

4. 实操过程与核心实现要点

4.1 Python 数据模型中必须掌握的方法清单

Python 把所有运算符都映射到了以双下划线命名的方法上，下表是实际开发中最常用的一组，我按照使用频率排序：

Python 有个“自动反向”的机制，值得细说。你实现了__lt__，当解释器遇到a > b时，会尝试a.__gt__(b)，如果没实现，就尝试b.__lt__(a)，因为a > b在逻辑上等价于b < a。所以理论上你只实现__lt__和__eq__，其余比较运算就能工作。但这里有个隐患：万一b的类型不是B而是B的子类，调用b.__lt__(a)时，子类的方法可能会被触发，产生难以预料的逻辑。稳妥的做法仍然是……能实现就都实现，别偷懒。偷懒省下的几行代码，会在某个深夜变成一场线上问题排查。

Python 3 还有一个强制规则：实现了__eq__的类，它的__hash__会被自动设为None。这导致该对象变成不可哈希的，放进set或作为dict的键直接报错。如果你的类型确实是可哈希的（业务上不可变），必须在类里显式加一行__hash__ = object.__hash__或用自定义实现。这个坑我已经在好几个项目里替别人填过了。

4.2 C++ 里的运算符重载写法与 C++20 新特性

C++ 运算符重载的语法是把operator和符号当作函数名。比如：

class Complex { public: double real, imag; Complex(double r, double i) : real(r), imag(i) {} Complex operator+(const Complex& other) const { return Complex(real + other.real, imag + other.imag); } Complex& operator+=(const Complex& other) { real += other.real; imag += other.imag; return *this; } bool operator==(const Complex& other) const { return real == other.real && imag == other.imag; } };

这里有一个 C++ 特有的要点：operator+=返回引用、修改自身，operator+返回新对象、不修改自身。两者语义不同，但通常建议两个都实现。一个常见优化是：operator+内部直接调用operator+=：

Complex operator+(Complex lhs, const Complex& other) { lhs += other; return lhs; }

注意lhs按值传入，函数内修改的是副本，天然满足“不修改原操作数”的约束。这种写法在很多现代 C++ 库（包括标准库的std::string）里被广泛使用。

C++20 引入了三路比较运算符<=>（飞船运算符），配合= default，可以一键生成全部六个比较运算：

#include <compare> class Money { public: int amount; std::string currency; auto operator<=>(const Money&) const = default; bool operator==(const Money&) const = default; };

只写这两行，==、!=、<、<=、>、>=全部可用，而且逻辑严格一致。这是我强烈推荐的做法——手动写六个比较运算太容易出错了，尤其是漏写!=导致a != b走到表达式取反，性能尚可但语义链路过长，还容易在代码审查里被挑刺。

C++ 的重载还有一个 Python 没刻意强调的点：operator<<的重载用于输出。让自定义类型可以直接std::cout << obj，方法是实现：

friend std::ostream& operator<<(std::ostream& os, const Money& money) { os << money.amount << " " << money.currency; return os; }

这里必须用友元函数而不是成员函数，因为左侧操作数是std::ostream，成员函数要求左侧是Money实例，方向反了。注意运算符重载里“左右操作数”的方向决定了函数的签名，这是新手最常犯的错误。

4.3 反向运算、就地运算与增强赋值：一个都不能少

反向运算（反向方法）是最容易被忽略的部分。它的触发场景是：当前对象的类型不是左操作数，而是右操作数。比如int * vector，Python 发现int的__mul__不知道如何处理Vector2D，就尝试调用Vector2D.__rmul__。

为什么不直接让int.__mul__失败算了？因为 Python 的int类型本身也可以和int子类运算，如果子类定义了__rmul__，这个反向调用给了子类“接管运算”的机会。在实际编码里，我只推荐在以下几种情况下实现反向方法：

• 你想支持“内置类型/其他库类型在左、自己的类型在右”的写法，比如2 * vec；
• 你想支持混合运算，比如int + Fraction，同时不想修改int的源码。

反向方法的实现有一个金标准：尽量不要直接实现，而是转发到正向方法。就像前面写的：

def __rmul__(self, scalar): return self.__mul__(scalar)

这样保持了逻辑的单点维护。如果正向方法里有类型检查，反转后同样生效。但要注意：__rsub__不能直接转发__sub__，因为a - b和b - a在数学上方向相反。正确姿势是：

def __rsub__(self, other): # other 在左，self 在右：实现为 other - self return Vector2D(other.x - self.x, other.y - self.y)

增强赋值运算（+=、-=、*=等）同样需要关注。Python 里的协议是：a += b优先调用a.__iadd__(b)，如果没实现__iadd__，就退化为a = a + b。所以对不可变类型，不实现__iadd__也能工作，只是每次都会创建新对象；对可变类型，实现__iadd__可以原地修改，性能更好。

这里有一个很多老手都在用的技巧：通过__iadd__优化重复拼接。字符串是不可变类型，s += s2新字符串生成的代价很高；但自定义的可变容器（比如内部维护一个列表的缓冲区）实现了__iadd__后，可以原地扩展列表，避免反复拷贝。在写需要高频拼接的数据结构时，这个优化能让性能提升一个数量级。

4.4 NotImplemented 与运算符重载的“合作机制”

聊 Python 的运算符重载，NotImplemented是绕不开的核心概念。它是 Python 解释器在运算符分发时的“信号灯”——返回它，表示“我不认识这种类型的操作数，你试试别人吧”。

举个具体流程。执行custom_obj + 42：

1. 调用custom_obj.__add__(42)；
2. 如果__add__返回NotImplemented，说明custom_obj自己处理不了整数 42；
3. 解释器转向右操作数，尝试(42).__radd__(custom_obj)；
4. 如果右操作数也不认识custom_obj，则返回TypeError: unsupported operand type(s) for +。

这个机制的价值在于：它让不同库的类型可以协同运算，而不需要互相知道对方的存在。你写了一个Fraction类，和标准库的int运算时，int不认识你的Fraction，返回NotImplemented，你的Fraction.__radd__就可以接管。

但这里有个经典错误：在方法内部直接返回False或None而不是NotImplemented。比如：

def __eq__(self, other): if not isinstance(other, Money): return False return self.amount == other.amount

这段代码看起来没问题，但有一个隐患：Money(10) == "10"返回False，这通常符合直觉。但如果你返回的是NotImplemented而不是False，解释器会让右操作数的__eq__接盘——"10"的__eq__大概率直接返回False，结果相同。差别在哪？在子类场景。如果别人继承你的Money类，在子类里重写了__eq__，父类返回NotImplemented会让子类的逻辑有机会执行；父类直接返回False则会短路，子类的重写永远不生效。判断类型不匹配时返回NotImplemented，才是正确的合作姿态。

我自己踩过这个坑。当时写一个Price类，__eq__里对非Price对象直接返回False。后来另一个组继承了Price，重写了__eq__，但测试一直失败——定位半天发现是父类的短路回绝把子类的比较逻辑给“吞”了。从那以后我给自己定了一条规则：能在类型判断阶段返回NotImplemented的，绝不直接返回结果值。

5. 常见问题与排查技巧实录

5.1 运算符不生效、报错的典型原因

问题一：obj1 + obj2报 TypeError，但两个类明明都实现了__add__。

排查思路分三步：先确认obj1的类型是不是你认为的类型。Python 的type(obj1)打印出来看看，有可能是子类实例，而子类没有继承__add__。再确认__add__的方法签名有没有写错——比如写成了__add__(self, other, extra)，多一个参数，调用时必然报错。最后确认__add__方法有没有拼错，双下划线前后两个，少一个下划线就静默退化成普通方法，运算符完全感知不到。

问题二：vec * 2正常，但2 * vec抛异常。

这就是没实现__rmul__的典型症状。Python 中左操作数是int，int不认识vec，又找不到右操作数vec的反向方法，于是报错。排查时看一眼类里是不是只有__mul__没有__rmul__。顺手再检查一下__rmul__的返回值，反向方法也返回新对象，不能返回self，否则2 * vec之后vec莫名其妙变了，问题更隐蔽。

问题三：实现了__eq__之后，对象放进set里时报错 unhashable type。

这是 Python 3 最经典的联动问题。规则是：类里定义了__eq__，__hash__就被置为None。因为 Python 的字典和集合基于哈希表，而“相等且哈希一致”是哈希表正确工作的前提。如果对象可以相等比较，但哈希变了，哈希表就崩了。

解决方式分两派：如果你的对象业务上是不可变的（比如金额、坐标），就显式恢复哈希，__hash__ = object.__hash__或者自定义一个基于不可变字段的哈希；如果对象是可变的（比如一个会修改值的列表包装），则不要放进需要哈希的容器里，此时保持__hash__ = None反而是安全设计。可变对象的哈希本身就是个陷阱。

问题四：C++ 里a + b编译不过，报“operator+ 未找到”或匹配失败。

先看是否是“类型不匹配导致的隐式转换问题”。比如vec + 2.0而2.0无法隐式转换到Vector2D。解决方案是定义接受double的重载，或者让构造函数支持隐式转换（加explicit关键字则禁止隐式转换，注意取舍）。再看是否是“const 限定符问题”——成员函数没加const，而a是const对象，编译器找不到可调用的operator+。所有不修改成员变量的运算符重载函数，都应该标记为const。

5.2 对称性与一致性 bug 排查

对称性问题是运算符重载里隐蔽性最高的 bug 类别。举三个真实案例：

案例一：比较运算的“方向偏斜”。一个Temperature类实现了__lt__，但没实现__gt__。代码里写if t1 > t2:，Python 自动转换成t2 < t1，也能跑。但某天有人给Temperature加了一个子类，子类重写了__lt__，然后调用t1 > t2走的就是t2.__lt__(t1)，也就是子类的方法，而直接写t2 < t1时访问的是t2的实际类型方法——同样的表达式，逻辑居然不一样。排查这类问题，优先把类里所有比较运算符方法都列出来，看有没有缺失；缺失的补上，且实现逻辑保持对称。

案例二：__eq__返回了非 bool 值。Python 的__eq__不一定非返回True/False，有些库（比如 numpy）的__eq__返回数组，这在布尔上下文里会报“truth value ambiguous”错误。自定义类型不要学这个，老老实实返回bool。如果内部的比较对象是别的自定义类型，确保那个类型的__eq__也返回bool，否则会一层层传导出问题。

案例三：哈希与相等的“契约违背”。Python 的哈希表要求：两个相等的对象必须有相同的哈希值。最常见的 bug 是：__eq__比较的是id字段，而__hash__用的是另一个字段的哈希。两个对象业务上相等，但哈希值不同，放进set后会出现两个“相等的”元素共存，去重失效。最稳妥的实现方式：__hash__只基于__eq__里参与比较的那些字段计算。写一个简单的验证函数：

def check_hash_contract(obj1, obj2): assert (obj1 == obj2) == (hash(obj1) == hash(obj2))

跑一遍测试，能拦下绝大多数哈希契约问题。

5.3 性能陷阱：重载运算符不等于高效

运算符重载的语法简洁容易让人忽略性能，这里说三个实操中遇到的性能场景：

场景一：返回值的新对象开销。a + b + c + d链式相加时，Python 每次+都创建一个新对象，四个对象相加会产生三次中间分配。对于自定义数值类型，这个开销不可忽视。优化手段有两个：尽量在表达式内部复用已有的就地运算方法（但注意不要为了性能牺牲语义）；或者实现__add__时用__slots__减少实例内存。看看自己对象的__dict__动不动就 100 字节以上，性能敏感的类加__slots__能省下不少内存分配。

场景二：__eq__里的短路优化。如果比较运算昂贵（比如比较两个自定义复杂结构），先比较便宜的字段。比如比较两个Money对象，先比较币种字符串，不等就直接返回False，再比较金额数字。币种比较成本低，等值比较频率高，这个顺序能省去大量不必要的数字比较。

场景三：__contains__用错数据结构。调用x in container时，如果container内部是普通list，复杂度 O(n)；如果内部是set或 dict 索引，复杂的是 O(1)。在自定义容器里实现__contains__时，不要把成员判断写成“遍历找一遍”，而是用内部已有的索引结构去做快速查找。比如我实现过一个标签集合类型，内部维护了一个dict做索引，__contains__直接查字典——速度提升了 20 倍以上，代码量反而更少。

5.4 常见问题速查表

6. 什么时候不该重载：边界与克制

把运算符重载聊得这么深，最后必须泼一盆冷水：不是所有自定义类型都适合重载运算符。我见过把业务对象重载出花来的代码，阅读起来像天书，比如order * customer代表下单这种恶趣味——这种代码除了秀技巧，没有任何工程价值。

什么时候不该用？我总结了三个信号：

信号一：运算的语义不符合数学直觉。customer + order没有任何自然语义，硬要重载+只会让读代码的人反复确认这是不是“合并订单”。这类操作就老老实实用place_order(customer, order)这样的方法名，方法名能表达意图，运算符表达不了。

信号二：重载增加了学习成本却没有减少理解成本。如果一个自定义类型从没被人用算术运算表达过，那么引入+、*的重载就是在给团队增加记忆负担。衡量标准很简单：让一个新同事看一行重载运算表达式，他能立刻说出它做了什么吗？如果不能，就不要重载。

信号三：夹具类型（单纯的 DTO/POJO）不需要重载。如果一个类只是用来装载几个字段、没有核心运算逻辑，那实现__eq__和__repr__就够了，其他运算符纯属多余。DTO 的价值在于“结构清晰”，不在“能干活”。

运算符重载这门手艺，讲究的是一个“配得上”。为真正有运算语义的类型重载，让每个符号都承担稳定的直觉含义，不滥用、不炫技——做到这几点，自定义类型就会真正“智能”起来，而不是“花哨”起来。从我这些年的实操体会看，最好的重载是那些让调用方完全感觉不到重载存在的重载：一行vec * 2 + offset读过去，就像在用内置类型一样自然。这，才是运算符重载追求的终极体验。