super关键字仅负责将已计算好的参数原样传递给父类构造器，不处理任何业务逻辑；复杂初始化应在super()调用前通过局部变量完成数据准备、转换与校验。
super 关键字本身不处理“复杂业务逻辑”，它只负责把参数原样传递给父类构造方法。所谓“复杂初始化业务参数”，本质是子类在构造时做前置计算或转换，再把结果传给父类——关键在于参数准备阶段，而非 super() 调用本身。
明确 super() 的定位：参数搬运工，不是业务处理器
super() 只做一件事：把已计算好的值，按签名匹配的方式交给父类构造器。它不执行校验、不触发回调、不参与流程编排。真正的业务复杂性体现在 super() 之前那几行代码里。
- super("admin", generateId(), parseRole(config)) 是合法的，前提是 generateId() 和 parseRole() 已返回符合父类构造器要求的类型
- super(validateAndFormatName(rawName), computeAge(birthDate)) 同样可行，但 validateAndFormatName 必须返回 String，computeAge 必须返回 int
- 不能写 super(doBusinessLogicThenReturnName())，除非 doBusinessLogicThenReturnName() 的返回类型与父类构造器形参严格一致
常见复杂参数的准备方式
多数“复杂”来自数据来源异构、格式不匹配或需上下文推导。推荐在 super() 前用局部变量封装转换逻辑，提升可读性和可测性。
- 配置解析类参数：从 Properties 或 JSON 中提取字段，做非空判断、类型转换、默认值填充后，再传入 super()
- 组合字段生成主键：比如用前缀 + 时间戳 + 序列号拼出唯一 ID，再作为 String 传给父类的 id 参数
- 状态映射：将枚举、字符串码值（如 "ACTIVE"）转为父类所需的布尔或整型状态，避免父类构造器承担语义解析职责
- 依赖注入预处理：若父类构造器需要 Service 实例，而子类持有 Factory，可在 super(factory.createService()) 中完成实例创建
规避典型陷阱
看似复杂的参数传递，常因忽略访问控制或调用时机而出错。
- 父类构造器若为 private 或 package-private，即使签名匹配也无法通过 super() 调用
- 不能在 super() 行中直接调用可能抛异常的方法（如 new URL(input)），否则编译虽过，运行时异常会中断对象创建，且父类字段可能处于半初始化状态
- 避免在参数表达式中修改共享状态（如 static 计数器），因为构造器可能被并发调用，导致不可预期结果
- 若需多步校验，建议先完成所有检查并赋值给 final 局部变量，再一次性传给 super()，而不是分散在多个 super() 参数中逐个计算
链式构造中的参数流转策略
当子类自身有多个构造器时，应让“参数加工”集中在最终调用 super() 的那个构造器中，其他构造器通过 this() 委托过去。
- 推荐模式：public Student(String rawConfig) { this(parseConfig(rawConfig)); } → public Student(ParsedData data) { super(data.name, data.age); ... }
- 不推荐：每个构造器都重复写一遍 parseConfig() 和字段提取逻辑，既冗余又难维护
- 若父类构造器参数较多，可考虑引入 Builder 模式，在 build() 方法内统一准备参数并调用 super()
