应提取共用字段赋值逻辑为私有方法（如 _init_common），避免构造入口重复赋值；参数差异大时改用 dataclass 配合 __post_init__ 做归一化处理。
构造器中重复赋值的典型表现
当你看到多个 __init__ 重载（比如用 @overload 声明，或在动态语言中手动模拟多签名）里反复出现 self.name = name、self.age = age 这类赋值时，说明逻辑耦合过紧。Python 本身不支持传统意义上的构造器重载，所谓“多个构造器”通常是靠默认参数、*args/**kwargs 或类方法（如 from_dict、from_json）实现的——真正需要提取的是「初始化阶段共用的字段赋值逻辑」。
用私有初始化方法统一赋值
把所有公共字段赋值抽成一个带下划线前缀的实例方法，比如 _init_common，然后在各个构造入口里调用它。这不是语法糖，而是明确切割关注点：参数解析归各入口管，状态设置归统一方法管。
常见错误是把校验也塞进去，导致 _init_common 变得不可复用；或者漏掉 self 参数，调用时报 TypeError: _init_common() missing 1 required positional argument: 'self'。
示例：
class User:
def __init__(self, name: str, age: int):
self._init_common(name, age)
<pre class="brush:php;toolbar:false;">@classmethod
def from_dict(cls, data: dict):
return cls(data["name"], data["age"])
def _init_common(self, name: str, age: int):
self.name = name
self.age = age
# 不放 validate_name() 这类强校验——它可能依赖其他字段或外部状态
当参数结构差异大时，用数据类 + __post_init__
如果不同构造路径传入的数据形态差别很大（比如一个传 id 和 raw_data，另一个传 username 和 profile_json），硬凑到一个 _init_common 里会增加参数复杂度。这时更适合用 dataclass，把字段声明和后置处理分开。
__post_init__ 是唯一能保证在所有字段赋值完成后执行的钩子，适合做归一化（如把 raw_data 解析为 email）、轻量级约束（如 if self.age ）。
注意：如果字段用了 field(default_factory=...)，__post_init__ 里读到的就是已计算出的值；但若字段是 InitVar，必须显式接收为参数，否则会被忽略。
避免用 __setattr__ 拦截做通用赋值
有人想一劳永逸，在 __setattr__ 里判断字段名并自动赋值，这会导致三个问题：一是破坏明确性，谁在什么时候设了什么变得难以追踪；二是性能损耗，每次赋值都触发拦截；三是容易引发递归，比如在 __setattr__ 里又给 self.xxx 赋值，没加 super().__setattr__ 就崩了。
真正需要拦截的场景极少，比如日志审计或冻结字段检查——那也该限定在特定字段上，而不是泛泛而谈“所有赋值”。
如果你发现要靠拦截才能让多个构造路径保持一致，大概率是参数抽象不够，该回头重新设计初始化契约，而不是在运行时打补丁。
