__repr__ 应返回可被 eval() 解析的字符串或明确调试标识，如 "User(name='alice', age=30)"；__str__ 面向用户，简洁可读；__eq__ 必须配对实现 __hash__（设为 None 或基于不可变属性）；__len__ 必须返回非负 int；__bool__ 优先于 __len__ 控制真值。
__str__ 和 __repr__ 别混用，尤其别在 __repr__ 里返回非合法 Python 表达式
很多人把 __repr__ 当成“更详细的 __str__”，结果返回类似 " 的字符串——这看起来清晰，但违反了 __repr__ 的设计契约：它应该尽可能返回一个能被 eval() 解析还原对象的字符串（或至少是明确、无歧义的调试标识）。实际中，除非对象确实支持从字符串重建（比如 datetime），否则优先用格式化占位符加类名和关键属性，例如 "User(name='alice', age=30)"。如果做不到，就退回到带内存地址的兜底写法：f"{type(self).__name__}(0x{id(self):x})"。
-
__str__面向终端用户，可读、简洁、可本地化；__repr__面向开发者，明确、无歧义、宜调试 - 日志、
print()、交互式解释器默认调用__str__；repr()、容器__repr__、异常 traceback 默认调用__repr__ - 若只实现一个，优先实现
__repr__；__str__缺失时会 fallback 到__repr__，但反过来不行
__eq__ 必须配对实现 __hash__，否则实例无法进 set 或作 dict 键
定义 __eq__ 时忘了重写 __hash__，是导致 TypeError: unhashable type 的高频原因。Python 规则很明确：只要重写了 __eq__，且逻辑上对象是可变的（或你不想让它可哈希），就必须显式设 __hash__ = None；如果对象逻辑不可变（如自定义的 Point），则应提供一致的 __hash__ 实现，且必须确保相等的对象哈希值相同。
- 错误示范：
def __eq__(self, other): return self.x == other.x and self.y == other.y，但没动__hash__→ 实例自动失去哈希能力 - 正确做法一（不可哈希）：
__hash__ = None - 正确做法二（可哈希）：
def __hash__(self): return hash((self.x, self.y))，且确保x、y不可变 - 注意：继承自
object的默认__hash__基于id()，一旦你定义了__eq__，这个默认行为就被禁用
__len__ 返回值必须是非负整数，且不能是 float 或 None
__len__ 的返回类型约束非常严格：必须是 int，且不能为负数。返回 float、None、字符串甚至 np.int64 都会触发 TypeError: 'xxx' object cannot be interpreted as an integer。这不是隐式转换问题，而是 CPython 底层直接检查类型。
- 常见踩坑：用 NumPy 数组长度做返回值 →
np.int64不被接受；应显式转int(len(self._data)) - 空容器应返回
0，不是None或False - 如果长度计算代价高（比如远程分页计数），不要在
__len__里做，改用显式方法如.count()，避免用户误以为len(obj)是 O(1)
__bool__ 和 __len__ 的优先级关系容易被忽略
当同时定义了 __bool__ 和 __len__，Python 会优先调用 __bool__ 来判断真值；只有前者未定义时，才回退到 __len__。这意味着如果你只重写了 __len__ 却期望 if obj: 按长度非零来判断，那没问题；但一旦你加了 __bool__，哪怕只是临时调试打了个 return True，整个真值逻辑就变了，且不会报错——这是静默行为变更。
- 典型陷阱：在基类里加了
__bool__返回self.is_active，子类只重写了__len__，结果子类实例的真假判断完全不看长度 - 建议：除非有明确语义差异（如“存在性” vs “非空性”），否则不要同时实现两者；若必须，确保逻辑自洽
- 调试时可用
help(bool)或查__bool__是否存在于dir(obj)中，快速定位谁在控制真值
__hash__ 可能让对象在字典里消失，一个越界的 __len__ 返回值会直接中断解释器执行——边界不在文档里，而在 CPython 的类型检查逻辑中。
