__init__只做最小状态赋值，重操作拆为显式方法；优先组合而非滥用继承；方法应无副作用，避免self堆砌临时状态；慎用__getattribute__等魔术方法，以清晰直白为先。
把 __init__ 当成万能初始化入口，忽略职责边界
很多新手一写类就往 __init__ 里塞大量逻辑：读配置、连数据库、加载文件、校验参数……结果对象构造失败时堆栈深、错误难定位，且无法单独测试初始化各环节。
真正该放进去的只有「对象自身状态的最小必要赋值」。其他重操作应拆成显式方法，比如 connect()、load_config()，让调用者按需触发。
-
__init__中避免 I/O 操作（如open()、requests.get()） - 参数校验可保留，但复杂逻辑建议抽到
_validate_params()并显式调用 - 若必须延迟初始化，用
@property或__getattr__做懒加载，别硬塞进__init__
滥用继承替代组合，导致类爆炸和脆弱基类
看到“XX 是一种 YY”，就立刻写
Python 的鸭子类型和模块化更适配组合。继承只在「严格满足 is-a 关系 + 需要多态调度」时才成立，比如 FileReader 和 DatabaseReader 共享统一接口 read()，且上层用 isinstance(obj, Reader) 做类型判断。
立即学习“Python免费学习笔记（深入）”；
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
- 优先用实例变量持有依赖对象（如
self.parser = JSONParser()），而非继承 - 抽象基类（
ABC）比普通父类更适合定义契约，避免“空壳父类”污染继承链 -
super().__init__()在多重继承中容易漏调或重复调，不如显式调用目标类方法
把 self 当全局变量用，堆砌状态导致行为不可预测
在方法里不断给 self 赋值临时字段：self._temp_result、self._processed_items……最后谁也说不清哪些字段是对象固有状态，哪些只是某次调用的中间产物。
这会让方法难以复用、并发不安全、序列化出错，还掩盖了真正的数据流——本该是函数输入/输出的东西，被藏进了隐式状态里。
- 方法尽量无副作用：输入参数，返回结果，不修改
self（除非明确是 mutator 方法，如append()） - 临时计算结果用局部变量，别存
self；真需要跨方法传递，考虑重构为新类或用dataclass封装上下文 -
__dict__动态增删属性是危险信号，说明设计没收敛，该用__slots__或类型注解约束了
过度设计 __getattribute__ 和 __getattr__，破坏可读性与调试路径
为了“看起来优雅”，用 __getattribute__ 拦截所有属性访问，自动路由到嵌套对象、动态生成方法、甚至查字典 fallback……结果 print(obj.x) 报错时根本看不出 x 是不存在、被拦截了、还是抛了异常。
这些魔术方法不是语法糖，是调试地狱入口。95% 的场景，用显式委托（def x(self): return self._inner.x）或 @property 更直白可靠。
-
__getattr__只应在「明确知道某些属性缺失时有合理 fallback」时使用（如兼容旧字段名） -
__getattribute__几乎不该碰；真要代理，优先用__getattr__+ 显式super().__getattribute__() - IDE 和静态检查工具（如 mypy）对魔术方法支持弱，会导致类型提示失效、跳转失效
最难的不是写出能跑的面向对象代码，而是忍住不用那些“看起来很酷”的机制。每次加一个 __ 开头的方法，先问自己：不用它，能不能靠更直白的函数、更清晰的字段、更小的类来解决？
