非受检异常专为“程序违约”设计，即代码违反自身约定（如传null、越界、状态非法），应在编码或测试阶段发现并修复；环境异常（如网络中断、DB失败）属外部不确定性，应归受检异常或专用错误模型处理。
非受检异常（RuntimeException 及其子类）不是用来兜底运行时意外的，而是专为“程序违约”设计的——即代码违反了自身约定或前提条件。它和“环境异常”（如网络中断、磁盘满、第三方服务不可用）有本质区别，后者属于外部不确定性，不应归入非受检范畴。
哪些算“程序违约”？
这类问题本可在编码或测试阶段发现，根源在内部逻辑失守：
- 方法接收
null参数，而契约明确要求非空 → 抛NullPointerException或更语义化的IllegalArgumentException - 调用对象方法前未校验状态，比如对已关闭的流再调用
write()→ 抛IllegalStateException - 集合操作越界（如
list.get(10)但 size=5）→IndexOutOfBoundsException是典型信号，提示索引生成逻辑有误 - 业务规则硬约束被绕过，例如“订单必须关联有效用户”，但传入了未初始化的
user对象 → 自定义InvalidOrderStateException更清晰
哪些不算？别把环境异常塞进 RuntimeException
把外部波动当作“编程错误”处理，会混淆问题性质，破坏调用契约：
- 用户提交手机号格式错误 → 不是代码写错了，是输入校验失败，应返回结构化错误响应（如
400 Bad Request+ 错误码） - 调用支付网关超时或返回
503→ 属于基础设施不稳定，适合封装为受检异常（如PaymentNetworkException），或由重试/降级机制消化 - 库存查询时 DB 连接失败 →
SQLException是受检异常，应捕获后转为领域可理解的失败结果（如StockQueryFailed），而非直接 throwRuntimeException - 文件上传临时目录磁盘空间不足 → 环境资源限制，需监控告警+运维介入，不适宜用
IllegalStateException掩盖真实原因
设计时的关键判断线索
抛出非受检异常前，快速自问三个问题：
- 这个错误能否在单元测试里稳定复现？能 → 倾向程序违约
- 修复方式是不是改一行校验或加一个 guard clause？是 → 属于非受检适用场景
- 下游调用方是否需要根据这个异常做差异化处理（如重试、切换通道、提示用户）？需要 → 说明它承载业务语义，应走受检路径或统一错误模型
配合机制才能落地有效
单靠抛 RuntimeException 不解决问题。真正起作用的是配套实践：
- 在 CI 中用 SpotBugs 检查空 catch 和忽略异常，堵住“吞异常”漏洞
- Controller 层禁止 throws 受检异常，所有异常经统一处理器转为标准 JSON 响应
- Service 方法入口强制校验参数（
Objects.requireNonNull、Preconditions.checkArgument），让违约尽早暴露 - 日志中记录非受检异常时，附带上下文快照（如入参、当前状态机 stage），方便定位逻辑断点
