错误地将受检异常（如 ioexception）不加判断地包装为 runtimeexception 会丢失状态码、掩盖真实错误类型，导致监控失效、重试策略失灵和前端提示不准；自定义异常构造器若未校验负数状态码，可能引发运行时异常；应保留 cause、统一错误处理入口，并检查异常包装层、构造器及状态码使用点。
直接说重点：把受检异常（比如 ioexception）在 catch 块里不加判断地包装成 runtimeexception，再抛出，容易掩盖真实错误类型、丢失状态码语义，导致后续排查困难——这不是“增强健壮性”，而是制造逻辑失真。
状态码被丢弃，异常语义断裂
受检异常常携带业务级状态码（如 HTTP 状态码、自定义错误码），用于区分“文件不存在”（404）、“权限不足”（403）、“服务不可用”（503）等场景。若统一转为 RuntimeException 并只保留消息字符串，原始状态码就丢失了。
- 例如：
new IOException("HTTP 401: Unauthorized")被 catch 后变成throw new RuntimeException(e.getMessage())→ 401 信息只剩在日志里，无法被上层统一识别或重试策略捕获 - 后果：监控系统收不到结构化错误码，熔断器无法按状态码分级响应，前端也无法做精准提示
未校验负数状态码，引发二次异常
某些自定义异常类将状态码作为 int 字段传入，若构造时未校验，负数状态码可能被非法接受；后续在日志、序列化或状态路由中使用该值，可能触发 NegativeArraySizeException 或数组越界等运行时异常。
- 典型隐患代码：
public MyException(int code, String msg) { this.code = code; this.msg = msg; }—— 没有if (code - 一旦上游误传
code = -1，下游调用new int[code]或switch(code)就会崩溃，此时堆栈已远离原始错误点，排查成本陡增
正确转化应保留可追溯性
若必须将受检异常转为运行时异常，核心是“不丢信息、可识别、可操作”：
- 继承
RuntimeException，但保留原始状态码字段和 getter 方法（如getStatusCode()） - 构造时强制校验状态码范围：
if (code 999) throw new IllegalArgumentException(...) - 保留原始异常为 cause：
super(msg, cause)，确保堆栈完整 - 对外暴露统一错误处理入口（如 Spring 的
@ExceptionHandler），按状态码做分类响应，而非靠异常类型硬匹配
排查时优先检查这三个位置
发现状态码相关逻辑失真，立即定位：
-
异常包装层：搜索
new RuntimeException(.*e)、throw new RuntimeException，确认是否抹除了状态码字段 -
自定义异常构造器：检查所有含
code参数的构造方法，是否有负数校验 -
状态码使用点：查找
new int[code]、array[code]、switch(code)等语句，确认 code 来源是否可信
