绕过自定义__setattr__的唯一可靠方式是显式调用object.__setattr__(obj, name, value)或super().__setattr__(name, value)；直接操作__dict__虽可绕过但会丢失描述符、__slots__检查等机制。
动态设置属性时 __setattr__ 被绕过怎么办
直接用 object.__setattr__(obj, name, value) 或 type(obj).__setattr__(obj, name, value) 是唯一可靠方式。普通赋值如 obj.attr = val 会触发自定义 __setattr__，但 setattr(obj, name, value) 也会——它只是语法糖，底层仍走 __setattr__。想绕过校验或日志逻辑？必须显式调用父类实现。
- 常见错误：以为
setattr()能跳过__setattr__，结果校验照常触发，甚至引发递归调用 - 正确做法：在自定义
__setattr__内部，对受控字段做判断；需绕过时，用super().__setattr__(name, value)或object.__setattr__(self, name, value) - 注意
__slots__类型对象不支持任意动态属性，此时object.__setattr__也会抛AttributeError
__dict__ 直接写入 vs setattr() 的行为差异
对常规实例对象，obj.__dict__['key'] = val 确实绕过 __setattr__，但它也绕过了所有描述符（@property、__get__ 等）、__slots__ 检查、以及任何基于属性访问的封装逻辑。这不是“快捷方式”，而是降级到字典操作层面。
- 使用场景仅限：调试、序列化工具、极少数元编程框架内部（如
dataclasses初始化） - 风险点：若类定义了
__slots__，__dict__可能根本不存在；即使存在，写入后属性访问仍可能失败 - 兼容性问题：PyPy 和某些 C 扩展类（如
numpy.ndarray子类）可能不暴露可写的__dict__
用 types.SimpleNamespace 做动态容器的安全边界
SimpleNamespace 是少数几个“设计上就为动态属性而生”的标准类型，但它不是万能胶水。它的 __dict__ 是公开且可写的，__setattr__ 不做拦截，适合做配置载体或临时数据包，但绝不该替代有业务语义的模型类。
- 别把它当
dict用：没有.get()、不支持in判断、键名必须是合法标识符 - 不能继承扩展：子类若重写
__setattr__，就失去“无约束”特性；想加校验？不如直接写个带__slots__的空类 - 性能影响小，但调试体验差：IDE 无法推导属性，
help()不显示动态字段，类型检查器（mypy）默认报错
装饰器注入属性时为什么 __init__ 里拿不到
装饰器运行在类定义阶段，它修改的是类对象本身（比如往 cls.__dict__ 塞描述符），而不是实例。如果装饰器试图在 __init__ 执行前给实例塞属性，那它只能靠修改 __new__ 或依赖 __set_name__（针对描述符）。否则，所谓“注入”只是给类加了默认值，实例属性仍要靠首次访问或显式赋值才出现。
立即学习“Python免费学习笔记（深入）”；
- 典型陷阱：装饰器里写
instance.attr = default，但instance根本没创建，代码直接报NameError - 安全做法：用描述符 +
__set_name__实现延迟绑定，或在__init__末尾统一初始化（需约定调用父类__init__） - 第三方库如
attrs和dataclasses都走描述符或代码生成路径，不碰实例生命周期早期阶段
动态属性最隐蔽的风险不在语法层面，而在调试和协作场景：别人读代码时，根本看不到属性从哪来、何时生效、是否被覆盖。哪怕只用一次 setattr，也要确保它出现在明确的初始化上下文里，而不是散落在条件分支或回调深处。
