Python 的魔法方法（dunder 方法，如 __init__、__str__、__eq__、__getitem__ 等）本身调用开销极小，但其实际性能影响主要来自**实现逻辑的复杂度**和**隐式触发场景的频率**，而非方法名前后的双下划线语法本身。
魔法方法调用不比普通方法慢
CPython 中，dunder 方法的查找和调用机制与普通方法一致，都走属性访问 + 函数调用流程。例如：
-
obj[0]触发obj.__getitem__(0)，本质是查属性再 call，无额外解释器层开销； -
a == b调用a.__eq__(b)（或回退到b.__eq__(a)），也仅多一次方法查找和可能的回退判断； - 没有“魔法加速”或“魔法减速”——名字特殊，执行不特殊。
真正拖慢性能的常见原因
问题往往出在开发者对 dunder 方法的误用或过度设计上：
-
在
__eq__或__hash__中做重计算：比如每次比较都序列化整个对象、遍历大列表、读文件或发起网络请求； -
在
__str__或__repr__中格式化大量数据：日志频繁打印自定义对象时，低效字符串拼接会成瓶颈； -
__getattribute__或__getattr__过度拦截：尤其在热路径中动态代理或字段懒加载，容易引发递归或重复计算； -
容器类中
__len__返回len(self._data)却让_data是未缓存的生成器或需遍历的结构：导致len(obj)变成 O(n) 操作。
如何验证和优化
别猜，用工具定位：
立即学习“Python免费学习笔记（深入）”；
- 用
cProfile或py-spy抓住高频调用的 dunder 方法（如大量__eq__出现在集合操作中）； - 对关键 dunder 方法加简易计时（如用
@functools.lru_cache缓存__hash__结果，前提是对象不可变）； - 检查是否无意触发了回退逻辑：比如
__eq__返回NotImplemented会尝试反向调用，两次开销翻倍； - 避免在 dunder 方法里做 I/O、锁等待、或调用未知第三方函数——它们才是真正的性能黑盒。
一个典型优化示例
错误写法（每次 len() 都遍历）：
return sum(1 for _ in self._iterable) # O(n)！
正确写法（预计算或缓存）：
def __len__(self):return self._cached_length # O(1)，构造时或首次访问时计算
dunder 方法不是性能敌人，而是接口契约。写得干净、轻量、可预测，它们就只是 Python 表达力的一部分。
