Python魔法方法是对象模型的底层协议接口，决定对象与内置操作符及函数的交互方式；应通过内置函数调用而非直接调用dunder方法，且需正确返回NotImplemented以支持协议降级。
Python 的魔法方法（dunder 方法）本质是协议接口，不是语法糖，也不是强制规范——它们是 Python 对象模型的底层契约，决定了对象如何与内置操作符、函数和语义交互。用得好，能让自定义类像内置类型一样自然；用得随意，反而破坏一致性，引发隐晦 bug。
魔法方法的核心设计原理：协议驱动，而非继承驱动
Python 不靠父类约束子类必须实现哪些方法，而是靠“协议”——只要一个对象提供了特定名称的 dunder 方法，解释器就在对应场景自动调用它。比如：
- 有
__len__→ 支持len(obj) - 有
__iter__和__next__→ 可用于for循环 - 有
__add__→ 支持a + b（且当a.__add__(b)返回NotImplemented时，会尝试b.__radd__(a)）
这不是语法特例，而是解释器在字节码层面硬编码的调用逻辑（如 BINARY_ADD 指令先查左操作数的 __add__）。所以你不能“重命名”或“绕过”它——协议名是固定的，行为是约定死的。
常见误用：把魔法方法当普通方法调用
写 obj.__str__() 或 obj.__len__() 是反模式。正确做法是调用内置函数或操作符：
立即学习“Python免费学习笔记（深入）”；
- 用
str(obj)而非obj.__str__()（前者会 fallback 到__repr__，后者不会） - 用
len(obj)而非obj.__len__()（前者会校验返回值是否为非负整数，后者不校验） - 用
obj == other而非obj.__eq__(other)（前者处理NotImplemented并尝试对称调用）
直接调用 dunder 方法跳过了协议保障机制，等于手动绕开 Python 的一致性设计。
关键细节：返回 NotImplemented 而不是 NotImplementedError
当你的 __add__、__eq__ 等方法无法处理某类参数时，应返回 NotImplemented（注意：是对象，不是异常）：
-
NotImplemented是提示解释器：“我处理不了，请试试对方的反向方法（如__radd__）或降级逻辑” -
NotImplementedError是异常，表示“这个方法该由子类实现”，抛出会中断流程 - 错误示例：
def __eq__(self, other): raise NotImplementedError—— 这会让obj == 42直接崩溃，而不是安静地返回False
实用建议：从最简协议开始，逐步增强
别一上来就实现全部 dunder 方法。按使用场景分层添加：
-
可读性优先：
__str__（用户友好） +__repr__（开发者友好，尽量可执行） -
容器行为：
__len__+__getitem__→ 自动支持for、in、切片、解包 -
数值/比较：
__eq__+__hash__（若可变则设为None）；算术操作只加真正需要的，如__add__配合__radd__ -
上下文管理：用
__enter__/__exit__，比手写try/finally更清晰
每个方法都应严格遵循文档约定（如 __bool__ 必须返回 True 或 False），否则可能触发意外的真值判断结果。
