runtimeexception 应在业务规则严重违反、内部状态已损坏或需封装底层异常时显式抛出，以明确表达非法逻辑；避免用于可预期外部失败、用户输入错误等场景。
RuntimeException 不需要强制声明或捕获，但**显式抛出它，是有明确意图的编码行为**——不是为了“绕过编译检查”，而是为了清晰表达“此处逻辑非法、不可继续执行”。关键在于：抛出时机要精准，信息要具体，且不替代前置校验。
业务规则严重违反时
当输入或状态明显违背核心契约，且该错误无法通过正常流程恢复，应主动抛出 RuntimeException（如 IllegalArgumentException、IllegalStateException）。
- 参数值超出业务定义范围（如年龄为负数、订单状态非法跃迁）
- 调用前提未满足（如未初始化就调用 get()，而文档明确要求先 init()）
- 使用自定义异常子类更佳，例如 InvalidOrderStatusException extends RuntimeException，比泛型 RuntimeException 更易定位和处理
内部状态已损坏，无法安全继续
对象或系统处于不一致、不可信状态，继续运行可能引发连锁错误或数据污染，应立即中断。
- 缓存与数据库版本严重不一致，且无自动修复机制
- 线程安全边界被破坏（如并发修改共享状态后检测到脏数据）
- 配置加载失败导致关键组件缺失（如数据库连接池未初始化成功）
封装底层异常，统一向上暴露
调用第三方库或底层 API 时，其抛出的 checked 异常或非标准 RuntimeException 不宜直接透出。应捕获后转换为语义明确的业务级 RuntimeException。
- 避免暴露 Jackson、Hibernate 等框架内部异常（如 JsonProcessingException、HibernateException）
- 转换时保留原始 cause（new BusinessException("解析用户配置失败", e)），便于排查
- 确保日志中记录完整堆栈，但对外响应只返回结构化错误码和提示
不建议显式抛出的常见情况
以下情形更适合用防御性编程或 checked 异常，而非 RuntimeException：
- 可预期的外部失败（如网络超时、文件不存在）→ 应用 checked 异常或返回 Optional/Result 封装
- 用户输入格式错误 → 前端校验 + 后端参数绑定校验（如 @Valid），而非手动 throw
- 空值场景频繁且合理（如查询结果可能为空）→ 返回 null 或 Optional，而非抛 NullPointerException
- 仅用于“终止当前方法”但无明确语义（如 throw new RuntimeException("暂不支持")）→ 可读性差，应改用 UnsupportedOperationException 并注明原因
