如果你写过一阵子Python大概率撞上过这种“解释不通”的现象两个自定义对象用比较结果永远是False类里明明写了__init__打印出来还是一串__main__.X object at 0x7f...想把自定义对象塞进set却报了个unhashable type。这些问题的答案全都藏在魔法方法Magic Methods里。魔法方法就是那对“隐形手”的落点。你写下obj other解释器真正执行的是obj.__add__(other)你写len(obj)背后被调用的是obj.__len__()连for x in obj这种看着很像语法层面的事底层也依赖容器协议那一组魔法方法。换句话说魔法方法不是“奇技淫巧”而是Python对象与语言本身签下的协议。掌握它们你的类才能像内置类型一样被循环、切片、比较、运算、上下文管理等语法结构直接接纳。这篇内容适合已经能独立写代码、但总在对象行为上吃瘪的Python开发者。不需要你背完整张方法清单跟着场景过一遍理解哪些语法会触发哪些方法遇到诡异行为知道去哪排查就足够了。如果你刚装好环境、还在刷基础语法先把for、def、类的基本写法练熟再回来看收益会大很多。1. 魔法方法到底是什么先建立全景认知1.1 解释器眼中的“语法糖”很多人对魔法方法的第一印象是“双下划线方法”但真正的理解应该倒过来它们是解释器内置协议的实现入口。Python语言在设计时把很多操作符和语法结构定义成“可被对象自定义”的钩子。当解释器遇到特定语法它会优先尝试调用对象上对应的钩子方法而不是一刀切地执行某种固定逻辑。举个例子obj1 obj2并不是“Python天然知道怎么把两个对象加在一起”而是解释器先去查看obj1那个对象的类型找它有没有__add__方法。找到了就把它变成一次方法调用。如果没找到再尝试右侧对象的__add__反向版本都失败就抛出异常。整条链路跟你平时调一个普通方法没什么本质区别只不过触发者是解释器而不是你的代码。这种设计带来的直接好处是你可以让自定义类型拥有与内置类型几乎一致的语法体验。实现了一套容器协议之后自定义类可以被in、for、切片、len()等操作直接使用实现了数值运算协议之后自定义类可以参与算术表达式。这就是Python“鸭子类型”在语法层面的延伸——不要求继承某个基类只要求实现对应方法。1.2 魔法方法的一览分类魔法方法数量不少但分类之后很容易形成整体认知。我把平时用得到的分成几组每组的职责很清晰分组主要方法对应的语法/函数构造与析构__new__、__init__、__del__对象创建、初始化、销毁字符串表示__repr__、__str__、__format__repr()、print()、f{obj}比较与真值__eq__、__ne__、__lt__、__gt__、__bool__、、if obj数值运算__add__、__sub__、__mul__、__matmul__等、-、*、容器协议__len__、__getitem__、__setitem__、__contains__、__iter__len()、obj[i]、in、for属性访问__getattr__、__setattr__、__getattribute__obj.attr、obj.attr v上下文管理__enter__、__exit__with obj as x:可调用对象__call__obj(args)哈希__hash__hash(obj)、set、dict的键这张表不需要背实战里用到哪组回来看哪组就行。我自己的习惯是先把“字符串表示、相等比较、容器协议”这三组吃透因为它们是日常调试和设计数据模型时出现频率最高的。1.3 学魔法方法到底能解决什么实际问题学这个东西的收益远不是“在简历上多写一行”那么虚。最常见的一个实际场景是调试。print(obj)打出来一堆内存地址你想快速看清对象内部状态都得手动写辅助函数有了__repr__一行输出就把核心字段展示清楚几百个对象的批量排查效率立刻不一样。第二个场景是API设计。你写了一个库希望使用者的代码写起来像“母语”一样自然。比如你实现了一个时间序列类使用者希望直接ts[0]取第一条、len(ts)看长度、ts1 ts2做拼接。这背后如果没有魔法方法使用者的代码就会退化成ts.get(0)、ts.get_len()、ts.concat(ts2)这样的调用式心智负担明显更高。魔法方法本质上是在帮你把业务对象“包装”成语义自然的语法结构。第三个场景是排查问题。框架代码、标准库里到处是魔法方法的影子不理解协议看源码只能看到“表面逻辑”一旦出了诡异问题根本无从下手。我见过太多人把__getitem__的边界写错导致for循环多迭代一次或者切片结果不符合预期最后靠各种奇怪的判断条件补丁“绕路”。理解了协议后很多问题一次就能定位到根因。所以这不是一门“装饰性知识”而是真正决定你能否吃透Python运行机制的底层能力。2. 构造与析构一个对象的出生与离场2.1__new__和__init__谁是真正的构造函数几乎所有Python学习者都知道__init__是“初始化方法”但很少人意识到它并不是真正创建对象的那个家伙。一个对象从无到有的完整链条是这样的解释器先调用类型对象上的__call__也就是你写MyClass()时发生的第一次调用。type.__call__内部会先调用MyClass.__new__(MyClass, *args, **kwargs)用它来分配内存并返回一个原始实例接着解释器检查返回的实例是不是MyClass类型如果是再去调用__init__(self, *args, **kwargs)完成字段赋值等初始化工作。有一个细节容易踩坑如果__init__写了return并且返回了一个非None值Python会直接抛TypeError。原因很简单__init__不是构造函数而是“初始化器”语义上就不允许返回任何对象。同样如果你重写了__new__但返回的是别的类型的实例解释器会跳过本类__init__的调用。这条规则在继承一些不可变类型时特别容易让人困惑。实际开发中99%的情况只需要写__init____new__交给默认实现就行了。理解它的存在更多是为了读懂框架源码以及处理少数特殊需求。2.2 不可变子类与单例必须动__new__的两个场景什么时候必须亲自动手写__new__我遇到过两个典型场景都属于“默认行为撑不住”的类型。第一个是继承不可变内建类型。比如你想写一个“只接受整数、且值非负”的tuple子类。元组一旦创建就不可变你没法在__init__里做初始化后修改只能在__new__里做筛选和过滤然后返回加工后的实例。示例class PositiveIntTuple(tuple): def __new__(cls, items): filtered tuple(int(x) for x in items if int(x) 0) return super().__new__(cls, filtered) p PositiveIntTuple([-1, 2, 3, -4]) print(p) # (2, 3)第二个是单例模式。有些资源管理类连接池、配置管理器希望全局只有一个实例通过在__new__里检查cls._instance是否存在存在就直接返回旧实例否则创建后保存。这里要注意线程安全单例在并发场景下需要加锁否则两个线程可能同时创建出两个实例。另外提一句__new__的第一个参数是类对象cls调用默认实现要写成object.__new__(cls)。很多人忘记传cls然后得到一个“需要一个参数”的报错属于新手很常见的惯性错误。2.3__del__的真相别把资源清理寄托在它身上__del__这个名字太有迷惑性了很多人以为它等同于C的析构函数可以用来“确保”释放资源。但实际上__del__的调用时机是“对象的引用计数归零时”由解释器决定并不保证在确定的时间点发生。如果存在循环引用甚至可能一直推迟到垃圾回收机制运行时才触发。我的经验是文件、网络连接、锁这类资源永远用with去管理而不是依赖__del__。一旦你依赖析构函数某天程序退出时资源没释放、连接没关闭排查起来极其痛苦。__del__最多用来打印日志、做点轻量级的观察工作而且要自己兜底异常——因为方法里抛出的异常默认不会传播到调用方只会被解释器默默吞掉并打印一条warning。我自己只在调试阶段用它打印“对象被回收了”这类信息生产代码里基本不写。3. 字符串表示与比较对象到底“长什么样”3.1__repr__和__str__两副面孔很多新手分不清__repr__和__str__其实分法很简单__str__是给用户看的__repr__是给开发者看的。print(obj)会优先调用__str__repr(obj)和交互式命令行里直接敲变量名调用的是__repr__。如果类里只实现了__str__而没有__repr__print正常但repr和交互环境还是会返回默认的...object at...。一个容易被忽略的规则是如果类只定义了一个最好定义__repr__因为__str__在没有定义时会“借用”__repr__的实现。反过来则不成立。所以我的习惯是做数据类时先写__repr__让输出能完整还原对象的构造参数再考虑要不要单独写面向用户的__str__。容器类还有一个更隐秘的行为当你print([obj1, obj2])时列表内部展示元素用的是元素的__repr__而不是__str__。如果你只实现了__str__列表打印出来照样是一堆地址。这点踩坑的人特别多建议亲自试一次感受下。3.2__eq__、__hash__与排序补全这个操作在Python里默认走的是“身份比较”即两个变量是否指向同一个对象。自定义类不实现__eq__那么a b比较的是a is b。所以你写了两个字段完全相同的对象用比较照样是False。这大概是最常见的“魔法方法翻车现场”。实现__eq__有个连带后果一旦你定义了__eq__Python会把类的__hash__置为None对象就变成不可哈希了不能放进set也不能当dict的键。如果对象是不可变的想同时支持相等比较和哈希必须同步实现__hash__而且哈希值要基于那些参与相等判断的字段保证相等的对象哈希值一定相同class Coordinate: def __init__(self, x, y): self.x x self.y y def __eq__(self, other): if not isinstance(other, Coordinate): return NotImplemented return (self.x, self.y) (other.x, other.y) def __hash__(self): return hash((self.x, self.y))这里还有一个值得记住的对照组__ne__在多数情况下不需要单独实现。Python3对a ! b的处理是先尝试__eq__的否定结果完全没有__ne__也能正常工作。但如果你强迫症想实现规则是让它返回not self.__eq__(other)并注意处理NotImplemented。至于排序和比较、、、分别对应__lt__、__gt__、__le__、__ge__。标准库里有个functools.total_ordering装饰器可以偷懒你只要实现__eq__和其中任意一个比较方法装饰器会帮你补全其余四个。我很推荐在数据类上用不过要注意它本质上是运行时生成方法性能上比手写四个完整实现差一点性能敏感的库还是手动补齐比较好。3.3__bool__真值判断的最后一环if obj:这类判断Python遵循这样一条规则首先看类型有没有定义__bool__有就用它的返回值当布尔判断没有__bool__就看有没有__len__有就用len(obj) ! 0当结果两个都没有一律视为真。这个规则解释了为什么空列表、空字符串、空字典都是“假”的因为它们各自的类都实现了__len__。自定义类如果不写__bool__默认就是“永远为真”哪怕它内部数据为空。如果你的类有“空状态”概念比如一个数据包类没有任何消息时应该视为False那就实现__bool__返回内部是否有内容。一个细节__bool__必须返回布尔值如果返回None或整数Python3会直接报错。有些老程序员习惯返回0或1这是Python2时代的遗留习惯在Python3里已经不合法了。逻辑判断的组合场景里顺手实现一个__bool__非常提升体验。举个例子解析器结果类里让“解析失败”的结果对象在if result:中表现为False调用方代码会简洁很多。4. 容器协议让自定义类享受原生“待遇”4.1 只要两个方法for 循环自己就能跑容器协议最核心的两个方法是__len__和__getitem__。有趣的是Python的迭代机制对它们有很强的“回退”逻辑for x in obj会先尝试obj.__iter__如果没有就去尝试调用__getitem__从下标0开始依次取值直到抛出一个IndexError才停止。这意味着你甚至不需要显式实现迭代器只要实现__getitem__对象就能被for循环遍历。class Playlist: def __init__(self, songs): self._songs songs def __getitem__(self, index): return self._songs[index] def __len__(self): return len(self._songs) p Playlist([A, B, C]) print(len(p)) # 3 print(p[0]) # A for song in p: print(song) # A B C这个例子只有两个方法却已经支持len()、下标访问、for遍历。很多标准库函数也吃这套协议list(p)、tuple(p)、reversed(p)都可以跑。理解了这个回退机制你再看那些“为什么这个类没有__iter__也能迭代”的源码就不会懵了。不过要注意__getitem__接收的下标不只是整数。当切片语法出现时传入的其实是一个slice对象。比如p[1:3]里的1:3会被封装成slice(1, 3, None)传进方法。如果你直接把index透传给内部列表自动就支持切片了如果你想自定义切片语义必须先判断isinstance(key, slice)。4.2 切片、包含与键访问一个__getitem__的三种姿势一个看似简单的__getitem__实际上要应付三种请求整数下标、切片对象、以及可能的任意键类型。设计键值容器类时我建议在方法开头统一判断class KVStore: def __getitem__(self, key): if isinstance(key, slice): # 处理切片逻辑 start, stop key.start, key.stop ... else: # 处理单个键 ...千万别以为key一定是整数。如果你接受字符串键调用方写obj[name]时传入的就是字符串。这里最常见的坑是只处理了整数结果调用方一不小心传了个字符串抛出的异常信息让人摸不着头脑。还有一点__getitem__要自己负责抛出KeyError或IndexError因为很多语法结构会依赖这个异常信号。比如前面提到的for循环回退机制就是靠IndexError判断“取完了”。in运算符默认是“遍历整个容器然后逐个用比较”如果容器很大、比较逻辑又慢性能会很难看。覆盖__contains__之后你可以用哈希表或二分查找大幅提速class FastSet: def __init__(self, items): self._data set(items) def __contains__(self, item): return item in self._data4.3 可变容器与迭代器协议如果希望对象支持赋值和删除还要补上__setitem__和__delitem__。这两个方法配合__getitem__你的类就成了一个“野生可变容器”可以写obj[1] x、del obj[1]。我通常会额外注意边界条件比如不可变字段校验、越界处理最好在方法里显式抛出KeyError或IndexError让使用者通过异常类型快速定位问题。再往深一层就是__iter__。当你需要控制迭代顺序、或者迭代逻辑无法用“按顺序取下标”表达时就该实现它。一个普通的迭代器需要两个方法__iter__返回迭代器自身或新的迭代器和__next__返回下一个元素取完抛出StopIteration。很多新手写出迭代器类后发现for循环跑了一次就“废了”就是因为__iter__返回了self而迭代器的状态在一次完整迭代后已经耗尽。解决办法是让__iter__返回一个全新的迭代器对象或者每次都重置内部状态。生成器函数是迭代器协议的“便捷捷径”任何包含yield的函数都自动实现__iter__和__next__。我自己的选择是逻辑不复杂的容器迭代直接写生成器逻辑复杂、需要维护大量内部状态的才手写迭代器类。5. 运算符重载从__add__到__radd__再到__iadd__5.1 NotImplemented运算符调度的关键信号看一些框架源码时你会经常见到方法里写着return NotImplemented。这个NotImplemented单例和异常NotImplementedError完全是两回事前者是“告诉解释器我处理不了这个操作请试试别人的”后者是“这个方法还没写好直接报错吧”。以a b为例完整的调度顺序是先试a.__add__(b)如果它返回NotImplemented再试b.__radd__(a)这里注意参数顺序是反的如果b也返回NotImplemented最终才会抛TypeError: unsupported operand type(s)。所以判定两个对象是否支持加法不能只看左边对象的类。我见过不少人写__add__时一旦类型不匹配就抛TypeError结果每次都需要调用方自己排查为什么抛异常。正确的做法是返回NotImplemented把决定权交回给解释器让调度机制自己去尝试右侧对象的反向方法。5.2 反向运算凭什么1 obj也能成立反向运算方法__radd__、__rsub__、__rmul__等的价值在混合类型运算中体现得最明显。假设你写了一个Quantity类表示“带单位的数量”希望支持10 Quantity(5)这种用法。Python执行10 obj时会先尝试int.__add__(10, obj)整数类显然不认识你的Quantity返回NotImplemented接着解释器会尝试obj.__radd__(10)也就是你定义的方法。实现反向方法时有个小原则尽量把结果转换为“更具体”的类型来返回。也就是说Quantity.__radd__(10)应该返回一个Quantity对象而不是一个普通数字。否则下一次运算又得指望右侧还有一个能接住Quantity的反向方法很容易写出层层分支的丑陋代码。反过来如果你想表达“不支持某种混用”比如一个平面向量和一个三维向量相乘没有意义那就明确返回NotImplemented让解释器给出标准的类型错误而不是自己写一堆逻辑然后抛异常。这样错误信息更统一、更好排查。5.3 就地运算与实战一个向量类这类就地运算符对应的魔法方法是__iadd__。它的语义比__add__多一些细节如果类实现了__iadd__a b会直接调用a.__iadd__(b)并可能修改a本身如果没有实现Python会退回去执行a a b也就是用__add__的结果重新绑定到变量名上。对于可变对象我建议实现__iadd__来做原地修改避免每次都创建新对象对于不可变对象不实现__iadd__反而更符合语义——它会表现为“生成了新对象再绑定给旧名字”。这里有一个容易疏忽的点如果__iadd__没有返回新对象即原地修改后返回self或直接返回None隐式地会让a b的结果变成None。所以无论是否原地修改__iadd__都必须返回一个对象因为它和__add__一样结果会重新赋给左侧变量。来看一个完整的向量类把前面几组方法组合起来class Vector2D: def __init__(self, x0, y0): self.x x self.y y def __repr__(self): return fVector2D({self.x}, {self.y}) def __str__(self): return f({self.x}, {self.y}) def __eq__(self, other): if not isinstance(other, Vector2D): return NotImplemented return (self.x, self.y) (other.x, other.y) def __hash__(self): return hash((self.x, self.y)) def __add__(self, other): if not isinstance(other, Vector2D): return NotImplemented return Vector2D(self.x other.x, self.y other.y) def __radd__(self, other): print(ffallback to __radd__: {other}) return self.__add__(other) def __iadd__(self, other): if not isinstance(other, Vector2D): return NotImplemented self.x other.x self.y other.y return self def __neg__(self): return Vector2D(-self.x, -self.y) def __abs__(self): return (self.x ** 2 self.y ** 2) ** 0.5这个类支持打印、比较、哈希、相加、反向相加、原地累加、取负和求模长。测试v1 v2、1 v当然这里1 v会走到__radd__但加法逻辑只认Vector2D所以1 v最终会因other是int返回NotImplemented导致报错——这是个正常设计你不能让向量加整数有意义。如果想支持标量 向量需要在__radd__里额外处理。运算符重载用多了务必记住一个原则符号表达必须符合业务直觉。如果一个加法不能让人一眼看懂含义就别硬用老老实实提供.merge()之类的方法。6. with语句与属性魔法隐藏在两处语法背后的协议6.1 手写上下文管理器__enter__/__exit__的完整协议with语句是我日常使用频率最高的语法之一它背后的协议只有两个方法__enter__负责返回“资源对象”__exit__负责收尾。执行流程是先调用__enter__返回值赋给as后面的变量然后执行代码块无论代码块是否抛异常都会调用__exit__。__exit__接收三个参数异常类型、异常实例、traceback对象。当代码块正常结束时三者都是None当抛出异常时它们会被填上。如果__exit__返回True解释器会“吞掉”这个异常with块外部不会再看到它返回False或None则异常继续向上传播。这个返回值搞错很容易出现“异常被静默吃掉”的诡异现象。一个典型的手写例子是计时器import time class Timer: def __enter__(self): self.start time.perf_counter() return self def __exit__(self, exc_type, exc_val, exc_tb): self.elapsed time.perf_counter() - self.start print(felapsed: {self.elapsed:.4f}s) return False # 不吞异常 with Timer(): time.sleep(0.2)如果你想少写样板代码标准库的contextlib.contextmanager可以把生成器函数变成上下文管理器yield之前的代码对应__enter__yield之后的对应__exit__。不过动手实现一次__enter__/__exit__非常值得因为很多框架封装“事务”“锁”“连接”时都用这套协议理解了它读框架代码会顺畅很多。6.2__getattr__与__getattribute__属性访问的两次机会这两个方法名字很像行为却差异巨大。__getattr__只在“常规查找失败”时调用也就是说只有在属性真的不存在时才会触发而__getattribute__是每次访问属性都会调用不管属性存不存在。前者适合做智能默认值、动态代理、兼容老接口后者适合做访问审计、统一拦截。一个容易踩进的误区是在__getattribute__里访问属性比如return self.name会再次触发__getattribute__从而无限递归。要获取原始属性值必须显式调用object.__getattribute__(self, name)。而__getattr__没有这个问题因为它只在正常查找失败后才介入方法内部访问属性走的是正常逻辑。动态代理是__getattr__比较经典的用法。比如要写一个对象把属性转发给内部持有的真实对象class Proxy: def __init__(self, real): self._real real def __getattr__(self, name): attr getattr(self._real, name) return attr要注意这个实现有个隐患self._real这样的属性本身在第一次访问时也会经过__getattr__。好在你是在__init__里用self._real real赋值的后续查找_real能找到不会触发__getattr__。但如果赋的是self.__real real这类名字因为名称改写机制查找方向会变得更容易绕晕建议还是用普通属性名加自约定前缀。6.3 用__setattr__做属性校验的正确姿势参数校验如果能做在“赋值那一刻”比在函数入口处反复写if not isinstance(...)要干净得多。__setattr__就是干这个的每次执行obj.attr value都会先进入这个方法由它决定是放行、改写还是抛出异常。实现校验时的最大坑是避免递归。如果你在__setattr__里写self.foo foo会触发自身形成无限循环。正确的写入姿势是调用object.__setattr__(self, foo, value)绕开当前类的重载。如果你希望直接操作实例的字典也可以self.__dict__[foo] value但这种方式在存在__slots__的类里不适用。class Temperature: def __init__(self, celsius): self.celsius celsius def __setattr__(self, name, value): if name celsius and value -273.15: raise ValueError(Temperature below absolute zero) object.__setattr__(self, name, value)其实ORM里很多字段校验、配置系统的只读属性底层都是这套机制。比如让某些属性“赋值即抛异常”可以专门拦截指定名字或者配合property做更细粒度控制。我的建议是校验规则简单时用property多个字段统一校验、且规则会扩展时用__setattr__两者不要同时用否则逻辑重叠容易产生混乱。7. 综合实战把零散魔法方法收拢进一个数据类7.1 需求与第一步骨架理论知识聊再多不如亲手拼一个类。我选一个很常见的业务场景做一个“配置项集合”ConfigBag它内部保存一组键值配置外部使用者需要像操作字典和对象属性那样操作它。需求拆解一下支持len()、下标访问、切片、包含判断、迭代、打印、相等比较、以及像函数一样调用时导出全部配置。第一步先写骨架只做最基础的存储class ConfigBag: def __init__(self, **kwargs): self._data dict(kwargs)7.2 逐个加协议语法能力跟着长接着一步步补齐魔法方法。每补一个我会标注对应的语法能力变化class ConfigBag: def __init__(self, **kwargs): self._data dict(kwargs) # 字符串表示print 和 repr 都能看清内容 def __repr__(self): return fConfigBag({self._data!r}) def __str__(self): return str(self._data) # 容器协议len、下标、成员判断 def __len__(self): return len(self._data) def __getitem__(self, key): return self._data[key] def __setitem__(self, key, value): # 这里可以做统一校验比如 key 必须是字符串 if not isinstance(key, str): raise TypeError(key must be str) self._data[key] value def __delitem__(self, key): del self._data[key] def __contains__(self, key): return key in self._data # 迭代协议直接迭代所有键 def __iter__(self): return iter(self._data) # 比较与哈希两个相同配置的袋子是相等的 def __eq__(self, other): if not isinstance(other, ConfigBag): return NotImplemented return self._data other._data def __hash__(self): # 注意这里要求 _data 的键值都可哈希配置项天然满足 return hash(frozenset(self._data.items())) # 可调用对象调用时导出全部配置 def __call__(self): return self._data.copy()到这里这个类已经“活”了。使用者可以写cfg ConfigBag(hostlocalhost, port8080) print(len(cfg)) # 2 print(cfg[host]) # localhost port in cfg # True for key in cfg: print(key) # host # port cfg2 ConfigBag(hostlocalhost, port8080) print(cfg cfg2) # True print(cfg()) # {host: localhost, port: 8080}7.3 效果对账表一句语法对应哪个魔法方法我把刚才实现的“语法能力”和“魔法方法”对一下账方便你以后设计类似类的时候查语法/函数触发的魔法方法实现前的表现len(cfg)__len__TypeErrorcfg[key]__getitem__不支持cfg[key] v__setitem__不支持key in cfg__contains__默认走迭代后逐个比较慢for x in cfg__iter__依赖__getitem__回退也可能跑但语义不一致print(cfg)__str__默认打印内存地址cfg cfg2__eq__比较的是对象身份永远Falsehash(cfg)__hash__不可哈希无法放set/dict键cfg()__call__TypeError: ConfigBag object is not callable这张表看着简单但已经把前面讲的核心协议串起来了。以后你接到“设计一个数据类”的需求可以先列出外部使用者可能写的语法再反推需要实现哪些魔法方法比对着文档逐条硬背高效得多。8. 常见问题与排查技巧实录8.1 五个高频翻车现象速查表我整理了平时在答疑和代码评审里遇到频率最高的翻车现场直接给结论现象根因解决办法print(obj)一直显示内存地址没实现__str__且容器场景下__repr__也没实现先实现__repr__打印问题九成解决len(obj)报TypeError类没有__len__实现__len__注意必须返回非负整数对象放进set报unhashable type定义了__eq__后__hash__被置为None同时实现__hash__基于相等判断字段计算if obj:永远为真没实现__bool__也没实现__len__按“空状态”语义实现__bool__或__len__a b结果变成None实现了__iadd__但忘了返回self所有就地运算方法都返回一个对象通常是self这些坑我自己都踩过不止一次。尤其是__hash__那个写数据类时顺手定义了__eq__然后兴致勃勃把它塞进set结果报错后查了半天才发现是哈希被自动禁用了。后来我养成了一个习惯在类里定义__eq__后立即问自己“这个对象需要放进set或当dict键吗”需要就立刻同步实现__hash__。8.2 排查魔法方法问题的三个习惯排查魔法方法问题时别靠猜我习惯按顺序做三件事。第一用dir()看对象暴露了哪些魔法方法。dir(obj)的输出会包含大量__xxx__项可以快速确认某个方法是否真的定义了。注意dir()也会显示继承来的方法所以看到某个方法存在不代表是当前类定义的配合type(obj).__dict__可以确认是不是“本类直接定义”。第二用repr()观察对象输出的具体值。如果你已经实现了__repr__一行输出往往就能暴露字段是否赋值正确、内部状态是否异常。比如我排查“两个对象总是False”时第一步就是分别repr()两个对象肉眼对比字段差异。第三用inspect.getsource(obj.__class__.__eq__)直接看方法源码。如果类是从第三方库继承来的与其猜测它内部逻辑不如直接把定义它的源码找出来看。这种“顺着魔法方法摸源码”的方式比在网上搜一堆零散答案要准确得多。8.3 关于何时别用魔法方法的一点看法最后想聊一个很多人不会说的点魔法方法不是越多越好更不是炫耀技巧的工具。如果一个类的核心需求只是“存一组值、取一个值”写普通方法.get()、.set()完全够用非要实现整套容器协议只会增加心智负担。魔法方法的最大价值是让“语法层面的表达”和“业务语义”对齐数据容器就喂给[]和len()数学对象就喂给和*资源管理就喂给with——这是“对位”关系而不是“能加就加”。我在实际写代码时会在设计阶段先写下“外部使用者希望怎么写”然后对照语法结构决定到底实现哪一组协议。能少写就少写避免为一个不常用的操作重载运算符造成歧义。比如给向量加标量这种“二义性操作”我宁可提供一个.scale()方法也不会强行定义__mul__然后让调用方猜“这个*到底是不是逐元素乘法”。踩过几次坑之后我自己的体会是魔法方法是Python给所有对象发的“语言公民证”。你不一定要把所有证都领全但至少要清楚每个证对应哪些语法权利用到时能精准领、快速查。等你某天看到类里一堆双下划线方法不再觉得神秘密码而是像读一份协议清单一样顺畅说明你已经真正掌握它们了。