多个构造器复用初始化逻辑应抽成私有方法（如init()），避免this()调用限制；Kotlin data class需依赖init块且次构造器必须委托主构造器；Python禁用__dict__操作，统一用_setup_*方法；Go推荐New函数封装校验与默认初始化。
Java 多个构造器怎么复用初始化逻辑
直接把公共初始化代码抽成私有方法，别用 this() 互相调用——后者容易绕晕、还限制必须是第一行，一加条件判断就崩。
常见错误现象：Constructor call must be the first statement in a constructor；或者改着改着发现某个构造器漏了字段赋值，运行时 NullPointerException 才暴露。
- 所有构造器末尾统一调用
init()或validateAndSetup()这类语义清晰的私有方法 - 初始化字段、校验参数、分配资源等操作全塞进这个方法里，不分散
- 如果某些构造器需要跳过部分初始化（极少见），就在方法里加参数控制，而不是另起一套逻辑
Kotlin 中 data class 构造器共享初始化的现实约束
data class 的主构造器绑定属性声明，没法像普通 class 那样自由写多个构造器体；想复用初始化代码，只能靠 init 块，且它只属于主构造器。
使用场景：你写了 constructor(a: Int) : this(a, "default") 这种次构造器，但发现 init 块没被触发——因为 init 只在主构造器执行路径中跑一次。
- 次构造器必须委托给主构造器（用
: this(...)），否则init块完全不执行 - 校验逻辑尽量放在
init块里，而不是每个次构造器里重复写require(a > 0) - 避免在
init块里访问this引用的未初始化属性（Kotlin 编译器会报错，但错误信息模糊，常误以为是空安全问题）
Python __init__ 里提取共用逻辑的坑：别碰 self.__dict__
有人图省事，在多个 __init__ 分支里直接操作 self.__dict__.update(...)，结果破坏了属性访问控制、绕过 @property setter、还让 IDE 和类型检查器彻底失联。
性能影响不大，但可维护性断崖下跌——别人 grep self.name = 找不到赋值点，调试时也看不到实际初始化顺序。
- 统一用普通方法，比如
self._setup_common_fields(config)，里面老老实实写self.x = ... - 如果真要动态设一堆属性，用
setattr(self, key, value)，至少保留语法可追踪性 - 避免在
_setup_*方法里调用可能被子类重写的实例方法（self.prepare()），除非你明确设计为模板方法
Go struct 初始化要不要封装成 NewXXX 函数
Go 没有构造器概念，但多人协作时，裸写 MyStruct{Field: val} 很快就会失控：缺字段、类型错位、零值陷阱。New 函数不是“规范”，而是防呆刚需。
容易踩的坑：New 函数里不做必要校验，或者把所有字段都暴露成参数，导致调用时传 8 个参数还分不清哪个是哪个。
- New 函数只接收业务关键参数，其余用结构体默认零值或内部合理默认值
- 校验逻辑（如
if name == ""）必须放 New 函数里，不能等到第一次调用某个方法才 panic - 如果结构体字段含指针或接口，New 函数里要显式初始化（比如
logger: log.Default()），别留 nil 等着 runtime panic
最麻烦的不是语法怎么写，而是团队里有人坚持“构造器就该干干净净只赋值”，结果初始化校验、资源预热、上下文注入全散落在各处——查一个对象生命周期，得翻五六个文件。
