RuntimeException更受欢迎，因其将异常处理决策权交还开发者，避免编译器强制干预；它契合防御性编码与静态分析趋势，减少代码噪音，便于统一错误治理和可观测性建设，但不可滥用。
RuntimeException在现代编程语言中更受欢迎，核心原因在于它把异常处理的决策权交还给开发者，而不是用编译器强制干预逻辑流程。
符合“错误应由代码逻辑预防”的设计哲学
这类异常（如NullPointerException、ArrayIndexOutOfBoundsException）本质是程序缺陷的信号，不是外部不可控事件。现代开发强调防御性编码和静态分析工具（如IDE提示、SpotBugs、SonarQube），提前发现空值访问、越界操作等隐患，比事后用try-catch兜底更高效可靠。
- 写
a[i]前检查i < array.length && i >= 0，比包一层catch更清晰 - 用Optional替代可能为null的返回值，从源头减少NPE风险
- Lombok的@NonNull或IDEA的@NotNull注解可触发编译期警告，防患于未然
避免受检异常带来的代码噪音
Checked Exception要求每个调用链都显式声明或捕获，容易导致：
- 大量重复的、无实质处理逻辑的try-catch（比如只打印日志后原样抛出）
- 方法签名膨胀，接口频繁变更只为加一个throws IOException
- 异常被“吞掉”——空catch块或仅e.printStackTrace()，掩盖真正问题
而RuntimeException不参与编译检查，让API更轻量，调用方按需决定是否拦截，例如测试中允许快速失败，生产环境再统一做顶层兜底。
与函数式编程和现代框架天然契合
Spring、React、Kotlin协程等主流技术栈默认以RuntimeException为错误传播载体：
- Spring的@Service方法抛出RuntimeException会自动回滚事务，Checked Exception则不会
- React组件中throw Error直接触发Error Boundary，无需额外声明
- Kotlin用非空类型系统（String而非String?）压缩NPE发生空间，剩余Runtime异常更聚焦业务校验失败
便于统一错误治理和可观测性建设
现代系统倾向于集中处理所有未捕获异常：
- 全局异常处理器（如Spring的@ControllerAdvice）统一格式化响应、记录上下文、触发告警
- APM工具（SkyWalking、Datadog）将RuntimeException作为关键错误指标采集
- 通过自定义RuntimeException子类（如ValidationException、BusinessException）携带业务语义，比层层包装Checked Exception更直观
不复杂但容易忽略：受欢迎不等于可以滥用。过度依赖RuntimeException而不做前置校验或文档说明，反而会让调用方更难预判行为。关键是在“可预防”和“需响应”之间划清边界。
