runtimeexception用于暴露和修正内部逻辑缺陷，推动问题在开发测试阶段被发现修复；适用于参数非法、状态非法等不可恢复的编程错误，而非运行时兜底或业务异常处理。
RuntimeException 适用于暴露和修正代码内部逻辑缺陷，不是为了运行时兜底恢复，而是推动问题在开发或测试阶段就被发现和修复。
标示不可恢复的编程错误
当异常反映的是“调用方式本身错误”，就适合抛出 RuntimeException：
- 构造函数收到语义上不允许的 null 参数 → 抛 IllegalArgumentException
- 工具方法明确要求非空集合，却传入 null → 主动抛 NullPointerException（比静默失败更利于定位）
- 对象处于非法状态时被调用关键方法（如已关闭的流再 write）→ 抛 IllegalStateException
- 自定义业务异常需强调“这是 bug，不是正常业务分支” → 继承 RuntimeException，命名带 Illegal 或 Invalid 前缀（如 InvalidOrderStateException）
拦截可预防的逻辑漏洞
这类异常根源在于可控的内部行为，应在编码阶段主动设防：
- 访问未初始化或可能为 null 的对象前，用 Objects.requireNonNull 或显式判空
- 数组/集合操作前校验索引范围，或改用 for-each 避免手动越界
- 方法入口对参数做断言：年龄不能为负、ID 不能为空字符串、枚举值必须合法
- 状态变更后及时更新上下文，避免后续操作基于过期或残缺状态执行
区分不该用 RuntimeException 的情况
混淆用途会掩盖真实问题，破坏调用契约：
- 用户输入格式错误（如手机号少一位）→ 属于预期内的业务校验，应返回结构化结果（如 Result
）或由 Controller 统一转为 400 响应 - 第三方服务超时或返回 500 → 是外部不确定性，更适合受检异常或封装为特定错误码
- 余额不足、库存扣减失败 → 是正常业务流程分支，推荐用枚举状态（INSUFFICIENT_BALANCE）或领域结果对象表达
- 为省事在 service 层 throw new RuntimeException("查不到用户") → 掩盖空值来源，且 Spring 默认事务不会回滚
配合机制才能落地设计意图
不强制捕获只是起点，真正发挥价值需要工程实践支撑：
- 单元测试覆盖边界条件（null、负数、越界索引），让 RuntimeException 在 CI 阶段就暴露
- 静态检查工具（如 SpotBugs、ErrorProne）识别潜在 NPE 和类型转换风险
- 日志中记录 RuntimeException 的堆栈并关联请求 ID，便于快速归因到具体代码行
- 监控告警关注生产环境 Runtime 异常突增，作为代码质量退化的信号
