delattr 如何避免无限递归的防护写法

直接在 __delattr__ 中调用 delattr(self, name) 会导致无限递归并触发 RecursionError；正确做法是显式调用 Object.__delattr__(self, name) 绕过自定义逻辑。

delattr 触发 __delattr__ 时的递归陷阱

直接在 __delattr__ 方法里调用 delattr(self, name) 会导致无限递归——因为 delattr 内部会再次触发 __delattr__，形成死循环。常见报错是 RecursionError: maximum recursion depth exceeded。

绕过自定义 __delattr__ 的标准写法

必须跳过当前类的 __delattr__，委托给父类（通常是 object）的实现。正确方式是：

def __delattr__(self, name):     if name == 'some_special_attr':         # 自定义逻辑，比如清理资源         pass     # 关键：用 object.__delattr__ 绕过自身     object.__delattr__(self, name)

• 永远不要在 __delattr__ 里调用 delattr(self, name) 或 self.__delattr__(name)
• 显式调用 object.__delattr__(self, name) 是最安全、最明确的绕过方式
• 如果继承链中有中间类也重写了 __delattr__，且你希望跳过它，仍应直接调用 object.__delattr__，而非 super().__delattr__(name)（后者可能又落入递归）

需要拦截并有条件删除的典型场景

比如实现只读属性控制、动态代理、或属性访问审计时，需判断是否允许删除：

class ControlledAttrs:     def __init__(self):         self._locked = False 
def lock(self):     self._locked = True  def __delattr__(self, name):     if name == '_locked':         object.__delattr__(self, name)         return     if self._locked and not name.startswith('_'):         raise AttributeError(f"Cannot delete '{name}' in locked state")     object.__delattr__(self, name)


对特殊内部属性（如 _locked）应优先处理，避免误判
条件判断必须放在 object.__delattr__ 调用之前，否则无法拦截
注意属性名匹配逻辑：用 name.startswith('_') 比硬编码列表更灵活，但也更易漏判

getattr + delattr 组合使用时的隐性风险
有人想先检查属性是否存在再决定是否删除，写出类似 if hasattr(self, name): delattr(self, name)，这在重写 __delattr__ 时极易出错：

 hasattr 底层调用 getattr，不触发 __delattr__，看似安全
但紧接的 delattr 仍会触发你的 __delattr__，若其中又调用了 hasattr 或 getattr（比如做存在性校验），就可能间接引发递归
更稳妥的做法是：所有存在性判断都基于 self.__dict__ 或 vars(self)（仅对实例属性有效），避开描述符和 __getattribute__ 干扰

真正棘手的地方在于：递归不一定立刻暴露，它可能藏在嵌套的属性清理逻辑里，等对象销毁或 GC 时才爆发。