构造方法抛出异常会导致对象创建失败，即对象从未存在过；资源需显式清理，禁止调用可重写方法，受检异常须处理，Spring中将导致Bean创建失败。
构造方法抛出异常会导致对象创建失败
Java 中 new 表达式一旦在构造方法中抛出未捕获的异常，JVM 就不会完成对象实例化——此时 new 的返回值根本不会产生，对象引用为 null 的情况也不会出现（因为构造未成功，栈上连引用都没来得及赋值）。换句话说：**构造方法抛异常 = 对象从未存在过**。
- 不能靠 try-catch 构造调用后判空来“兜底”，因为异常抛出时对象生命周期根本没开始
- 所有在构造中分配的资源（如打开的文件、网络连接、线程）必须在 finally 或 try-with-resources 中显式清理，否则可能泄漏
- 如果使用了静态工厂方法封装构造逻辑，异常应明确声明或包装为更语义化的运行时异常（如
IllegalArgumentException、IllegalStateException）
不要在构造方法中调用可被子类重写的方法
这是最隐蔽也最危险的一点：若父类构造器中调用了 protected 或 public 方法，而该方法在子类中被重写，那么在父类构造尚未完成时，子类方法就会被执行——此时子类字段仍为默认值（0、false、null），极易触发 NullPointerException 或逻辑错误，甚至间接抛出异常。
- 这种调用发生在对象处于“半初始化”状态，JVM 不阻止但语义上不安全
- 即使子类方法里加了
try-catch，也无法改变父类构造已失败的事实 - 解决方式是把这类逻辑移到
init()方法中，或使用 final 方法、私有方法、静态工厂 + 构造参数校验替代
检查异常必须在调用处显式处理
如果构造方法声明了 throws IOException 这类受检异常（checked exception），那么所有 new Xxx() 调用都必须包裹 try-catch 或向上声明。这点和普通方法一致，但容易被忽略，因为日常写的构造方法大多不抛检查异常。
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
- 常见场景：构造中读取配置文件、连接数据库、解析 JSON 字符串等
- 错误写法：
MyService service = new MyService(); // 编译报错：unreported exception
- 正确写法：
try { MyService service = new MyService(); } catch (IOException e) { throw new RuntimeException("Failed to init MyService", e); } - 更推荐用静态工厂方法隐藏异常细节：
MyService.create()内部处理并统一转为运行时异常
Spring 等框架中构造注入失败会直接导致 Bean 创建失败
在 Spring 容器中，若某个 Bean 的构造方法抛出异常（无论是否捕获），整个上下文刷新就会中断，ApplicationContext 启动失败，并抛出 BeanCreationException，根因通常是原始异常（如 NullPointerException 或自定义业务异常）。
立即学习“Java免费学习笔记（深入）”；
- Spring 不会尝试“重试”或“跳过”该 Bean；依赖它的其他 Bean 也不会被创建
- 日志中关键线索是
Nested exception is后面的内容，要顺着它往上翻几行找真实异常堆栈 - 单元测试中若用
@Autowired注入失败，大概率是构造阶段出了问题，而不是 DI 配置错误 - 避免在构造中做重量级操作（如远程调用、大文件加载），既影响启动速度，又让异常定位变模糊
new 就结束了。 
