delattr 如何避免无限递归的防护写法
直接在 __delattr__ 中调用 delattr(self, name) 会导致无限递归并触发 RecursionError；正确做法是显式调用 object.__delattr__(self, name) 绕过自定义逻辑。
delattr 触发 __delattr__ 时的递归陷阱
直接在 __delattr__ 方法里调用 delattr(self, name) 会导致无限递归——因为 delattr 内部会再次触发 __delattr__，形成死循环。常见报错是 RecursionError: maximum recursion depth exceeded。
绕过自定义 __delattr__ 的标准写法
必须跳过当前类的 __delat，委托给父类（通常是 
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 时才爆发。
