Java编译器对构造器的处理是“非黑即白”：无显式构造器时自动插入public无参默认构造器；一旦声明任一构造器，默认无参构造器立即消失，导致子类隐式super()调用失败及框架反序列化异常，故需显式添加无参构造器或在子类中明确调用super(参数)。
因为Java编译器把“没写任何构造器”当作你希望它代劳的信号，而一旦你写了任意一个构造器（哪怕只是带参的），它就认定你要全权接管对象创建逻辑，于是自动撤回默认无参构造器。
编译器的默认行为是“非黑即白”
编译器不会半途而废——它不提供“部分默认”或“保留备用”的选项：
- 类中没有任何构造器声明 → 编译器悄悄插入一个 public、空体、无参的默认构造器
- 类中只要出现一个显式构造器（public Person(String name)、protected Car(int id)，甚至 private Helper()）→ 默认无参构造器立即消失，不留痕迹
子类实例化会暴露这个陷阱
子类构造器第一行隐含调用 super()，也就是父类无参构造器。如果父类因写了有参构造而丢失了无参构造，又没在子类里显式写 super(…)，编译直接报错：
- 错误提示示例：`Implicit super constructor XXX() is undefined. Must explicitly invoke another constructor`
- 这不是语法错误，而是编译器在提醒：父类那条“默认通行路径”已被关闭，你得手动指定走哪条路
框架和反射依赖无参构造器
Spring、Jackson、Hibernate 等主流框架在反序列化或依赖注入时，通常通过反射调用 Class.newInstance() 或类似机制——而这要求目标类存在可访问的无参构造器：
- 若类只有 public User(String email, String pwd)，但没写 public User() → 框架初始化失败，抛 NoArgsConstructorException 或 InstantiationException
- 使用 Lombok 时，@AllArgsConstructor 或 @RequiredArgsConstructor 不会生成无参构造，必须额外加 @NoArgsConstructor
怎么避免踩坑
不是靠记住规则去规避，而是主动设计：
- 只要类可能被继承、被框架管理、或需作为 JavaBean 使用，就显式写上 public 类名() { }
- 定义有参构造后，顺手补一个无参构造，哪怕只做最小初始化（如字段设默认值）
- 在子类构造器中，若父类无无参构造，第一行必须写 super(参数)，且参数类型要严格匹配父类某一个构造器
