构造器中抛出 runtimeexception 合法但不推荐，因对象创建失败易被框架包装掩盖原因，应优先用静态工厂方法校验并返回 optional 或明确异常。
构造器里 throw new RuntimeException 是合法的，但不推荐
Java 允许在构造器中抛出异常，包括 RuntimeException 及其子类（比如 IllegalArgumentException），编译器不会强制你声明或捕获。但问题在于：一旦抛出，对象实例化就失败，且调用方可能没准备处理——尤其在依赖注入、反射创建（如 Spring 的 BeanFactory）或序列化反序列化场景下，会直接中断流程，报错信息还常被包装成 InvocationTargetException 或 BeanCreationException，掩盖原始原因。
常见错误现象：new User("invalid@email") 抛出 IllegalArgumentException，但单元测试里只断言了字段值，没 catch 异常，结果测试直接 fail 而不是 assert 失败；或者用 Jackson 反序列化 JSON 时，构造器校验失败导致 JsonMappingException，堆栈里根本看不到你写的校验逻辑。
- 校验逻辑越简单越适合放构造器：比如非空、长度范围、枚举合法性
- 涉及外部依赖（数据库、HTTP、文件读取）的校验，绝不能放在构造器里——对象创建不该有副作用
- 如果类会被框架反射创建（Spring、Jackson、Hibernate），优先用
@PostConstruct或init()方法做校验，并明确抛出受检异常或返回Optional
用静态工厂方法替代构造器做校验更可控
直接调用 new 无法统一拦截或扩展行为，而静态工厂方法（比如 User.of(...)）可以封装校验、缓存、适配等逻辑，还能返回 Optional<user></user> 或自定义结果类型（如 Result<user></user>），让调用方显式处理失败路径。
使用场景：API 接收用户输入、配置加载、DTO 转换。此时你希望“构建失败”是可预期、可分类、可记录的，而不是靠 try-catch 到处兜底。
立即学习“Java免费学习笔记（深入）”；
-
User.of(String email)内部先校验邮箱格式，不合法直接 returnOptional.empty()，比抛异常更利于链式调用 - 若必须抛异常，工厂方法可统一 throw
IllegalArgumentException，并确保消息包含字段名和具体规则（如"email must match pattern: .*@.*\..*"） - 注意不要在工厂方法里 new 出来又立即 set 属性——这等于绕过构造器校验，破坏不变性
IDEA/Eclipse 中构造器异常不会自动提示，容易漏测
现代 IDE 对构造器里抛出的 RuntimeException 几乎不作任何检查或警告，不像受检异常那样强制处理。写完一个带校验的构造器，开发者很容易以为“只要编译过就安全”，结果上线后某个边界输入触发异常，才在日志里看到 java.lang.IllegalArgumentException: null 这种毫无上下文的信息。
性能影响很小，但兼容性风险高：JDK 14+ 的 Record 类不允许构造器抛异常；GraalVM 原生镜像在 AOT 编译阶段可能因反射调用失败而静默跳过校验逻辑。
- 所有带校验的构造器，必须配对应单元测试，覆盖每条异常路径（用
assertThrows） - 避免在构造器里调用可被子类重写的方法（
this.validate()），否则子类未初始化完成就执行逻辑，可能 NPE - 如果类实现了
Serializable，记得校验逻辑不能依赖 transient 字段或外部状态，否则反序列化时校验失效
Spring Bean 初始化时构造器异常会被吞掉一层
Spring 默认通过反射调用构造器创建 Bean，一旦抛出 RuntimeException，它会包装成 BeanCreationException，原始异常变成 cause。日志里看到的是 “Error creating bean with name 'userService'”，真正的问题却藏在 nested exception 中，排查时得手动展开三层堆栈才能定位到你的 new User(...) 行。
这不是 bug，是 Spring 的设计选择：它把对象创建视为原子操作，失败即终止。但这就意味着——你不能指望 Spring 自动帮你重试、降级或 fallback。
- 在
@Configuration类中用@Bean方法创建实例时，可在方法体里 try-catch 构造器异常，转为更明确的日志或提前退出 - 若校验依赖配置项（如
@Value("${app.min-age}")），别在构造器参数里直接注入，改用@PostConstruct+ 成员变量校验，否则配置缺失会导致IllegalArgumentException和UnsatisfiedDependencyException混在一起 - Spring Boot 2.6+ 默认启用
spring.main.allow-bean-definition-overriding=false，此时构造器异常还可能导致整个 ApplicationContext 启动失败，连 Actuator 端点都不可用
