非受检异常旨在暴露并修正逻辑缺陷，而非运行时恢复；其设计意图是通过不强制捕获来推动在编译前或测试阶段修复问题，如空指针、非法参数等可控内部错误。
非受检异常的设计初衷很明确：它不是为了让你在运行时“捕获并恢复”，而是为了帮你尽早暴露和修正代码中的逻辑缺陷。
核心设计意图：把错误挡在运行前RuntimeException 及其子类（如 NullPointerException、IllegalArgumentException、ArrayIndexOutOfBoundsException）被设为“非受检”，是因为编译器相信——这类问题本不该出现在生产环境。它们的根源几乎全是可控的内部行为：调用 null 对象的方法或字段 → 应在参数校验或对象初始化阶段拦截传入负数年龄或超长数组索引 → 应在方法入口做范围断言（Objects.requireNonNull、AssertJ 或手动 if throw）
非法状态下调用方法（如已关闭的连接再 write）→ 应通过状态机或 guard clause 提前拒绝Java 不强制 try-catch，就是在提醒你：别绕开问题，去修代码本身。
典型适用场景：标示不可恢复的编程错误只有当异常反映的是“调用方用错了方式”，才适合抛出 RuntimeException：构造函数收到 null 参数且语义上不允许 → 抛 IllegalArgumentException工具类方法要求非空集合，但传入了 null → 主动抛 NullPointerException（比沉默穿透更清晰）
服务方法依赖某个已初始化的上下文，但上下文为空 → 抛 IllegalStateException自定义业务异常需强调“这是 bug，不是业务失败” → 继承 RuntimeException，命名带 “Illegal” 或 “Invalid” 前缀（如 InvalidOrderStateException）
哪些情况不该用 RuntimeException？
一旦混淆用途，就会破坏调用契约和系统可维护性：用户输入格式错误（如手机号少一位）→ 不是程序逻辑错，应返回 Result
第三方接口返回 500 或超时 → 属于外部不确定性，更适合受检异常或封装为特定错误码余额不足、库存不够等业务规则不满足 → 是正常流程分支，不应中断调用栈，推荐用枚举状态或领域结果对象表达为图省事在 service 层 throw new RuntimeException("查不到用户") → 掩盖真实问题，且 Spring 默认事务不会回滚（除非显式配置 rollbackFor）
配合机制才能发挥设计价值单靠“不强制捕获”不足以落地预防理念，需要配套实践：启用 IDE 静态检查（如 IntelliJ 的 Nullability 注解 + @NotNull/@Nullable）
单元测试覆盖边界值和非法输入，让 RuntimeException 在测试阶段就炸出来使用 Optional 表达可能为空的返回值，把“是否为空”从隐式风险变成显式契约全局异常处理器（@ControllerAdvice）统一拦截 RuntimeException 并记录堆栈，但不做业务逻辑恢复