runtimeexception本质是代码缺陷而非外部错误，应精准预防而非兜底捕获；如nullpointerexception等均源于逻辑疏漏，需在编码阶段通过校验、初始化等手段主动规避。
RuntimeException 不该被“兜底捕获”，而应被“精准预防”和“分层响应”。它本质是代码缺陷的信号，不是外部不确定性事件——放任不管或粗暴 catch，反而会掩盖真实问题，动摇系统稳定性根基。
Runtime 异常的本质是 Bug，不是错误
NullPointerException、ArrayIndexOutOfBoundsException、ClassCastException 这些都不是网络抖动或磁盘满这类外部风险，而是逻辑疏漏的直接体现。JVM 不强制处理它们，正是为了倒逼开发者在编码阶段就堵住漏洞。
- 空指针：调用前没做 obj != null 判断，或依赖未初始化的字段
- 数组越界：循环条件写成 i ，或硬编码索引值
- 类型转换异常：跳过 instanceof 直接强转，或泛型擦除后误判类型
不捕获 ≠ 不处理，关键在预防与暴露
与其在 service 层写个空 catch 吞掉 NullPointerException，不如让异常立刻抛出、触发告警、进入监控大盘。这样问题才能被看见、被修复。
- 单元测试覆盖边界场景（如传 null、空集合、负数参数），提前暴露运行时异常
- 使用 IDE 静态检查插件（如 IntelliJ 的 inspections）标出潜在空指针路径
- 在 CI 流程中接入 FindBugs 或 SpotBugs，拦截高危模式（如可能的 NPE 调用链）
必须捕获的例外：框架层兜底与日志归因
两类场景下需要显式 catch RuntimeException：
- 线程长期运行场景：定时任务、消息消费者、WebSocket 连接处理器。一旦未捕获，线程静默退出，后续任务丢失，必须用 try-catch + 记录完整堆栈 + 告警
- 用户请求入口层：Controller 或 Gateway。捕获后统一转为 500 响应，附带 traceId，但绝不返回原始堆栈给前端
所有 catch 块必须记录 e 本身（不是只打一句 “出错了”），确保上下文可追溯。
资源清理不能依赖异常处理逻辑
RuntimeException 可能在任意位置抛出，如果资源（文件流、数据库连接、FFI 句柄）靠 finally 手动释放，极易遗漏。正确做法是：
- Java 用 try-with-resources，编译器保证 close() 执行
- .NET 用 using 语句，等效于 try-finally
- php-raylib 等 FFI 场景，严格配对 load / unload，并在 finally 中显式调用 unload
资源泄漏不会立刻崩溃，但会随时间推移拖垮系统——连接池耗尽、内存持续增长、句柄数超限，这才是稳定性真正的慢性杀手。
