java编译器对构造器的处理是“非黑即白”：无显式构造器时自动插入public无参默认构造器；一旦声明任一构造器，默认无参构造器立即消失，导致子类隐式super()调用失败及框架反序列化异常，故需显式添加无参构造器或在子类中明确调用super(参数)。
因为Java编译器把“没写任何构造器”当作你希望它代劳的信号，而一旦你写了任意一个构造器（哪怕只是带参的），它就认定你要全权接管对象创建逻辑，于是自动撤回默认无参构造器。
编译器的默认行为是“非黑即白”
编译器不会半途而废——它不提供“部分默认”或“保留备用”的选项：
- 类中没有任何构造器声明 → 编译器悄悄插入一个 public、空体、无参的默认构造器
- 类中只要出现一个显式构造器（public Person(String name)、protected Car(int id)，甚至 private Helper()）→ 默认无参构造器立即消失，不留痕迹
子类实例化会暴露这个陷阱
子类构造器第一行隐含调用 super()，也就是父类无参构造器。如果父类因写了有参构造而丢失了无参构造，又没在子类里显式写 super(…)，编译直接报错：
Codex Auth Cleaner
下载
一款AI工具，主要用于Monitor and clean up invalid Codex authentication files in CPA. Check quota status, disable files returning 401 errors, and perform dual verification before deletion.，适合需要提升相关任务效率的用户。
- 错误提示示例：`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(参数)，且参数类型要严格匹配父类某一个构造器
