显式声明 throws RuntimeException 不影响编译与运行，但能提升 API 可读性、协作效率及工具链支持；仅应对有意抛出的、具业务语义的异常声明，避免过度使用。
方法签名加上 throws RuntimeException 不会影响编译或运行行为，但会明确传递设计意图。
不改变程序执行逻辑
RuntimeException 及其子类（如 NullPointerException、IllegalArgumentException）属于非受检异常。Java 编译器不要求必须声明或捕获它们。因此：
- 加不加
throws RuntimeException，代码都能通过编译 - 加了也不会强制调用方写 try-catch 或继续 throws
- 运行时该抛还是抛，JVM 不会因 throws 声明而多做任何事
提升 API 可读性与协作效率
虽然不是必需，但显式写出 throws 能让使用者一眼看出这个方法可能在哪些业务条件下主动抛出异常：
- 比如
public User findById(Long id) throws IllegalArgumentException，提示调用者：id 为 null 或负数时会失败 - 团队开发中，它相当于一种轻量级契约说明，减少“为什么突然空指针”的排查成本
- 配合 Javadoc 使用，能形成更完整的接口文档
支持工具链与静态检查
部分 IDE 和代码分析工具（如 SonarQube、Checkstyle）可配置规则，鼓励对常见业务异常做 throws 声明。这样：
立即学习“Java免费学习笔记（深入）”；
- 便于生成 API 文档时自动提取异常信息
- 有助于识别“本该校验却漏了 throw”的逻辑缺口
- 在重构或 mock 测试时，更容易把握方法的失败路径
注意避免过度声明
不是所有 RuntimeException 都值得写进 throws：
- 纯编程错误（如 NullPointerException 因未判空）不该声明——应修复代码，而非预告错误
- 只对有意 throw 的、有明确业务语义的异常（如
throw new IllegalStateException("状态非法")）才建议声明 - 若 throws 列了一长串 RuntimeException，反而模糊重点，失去提示价值
