非受检异常不提升高并发系统健壮性，反而可能放大雪崩风险；真正关键的是明确错误语义、可控失败边界和异步容错机制。
非受检异常本身不提升高并发下的系统健壮性；相反，若缺乏配套设计，它可能放大雪崩风险。真正支撑高并发稳定性的，是明确的错误语义、可控的失败边界和异步容错机制，而非是否“强制捕获”。
非受检异常在高并发中容易暴露的脆弱点
在请求量陡增时，非受检异常的隐式传播特性会快速击穿薄弱环节：
- 链路阻塞无感知：一个服务抛出 IllegalArgumentException，调用方未做适配，整个同步调用链直接中断，无法降级或重试；
- 错误信息不可聚合：不同模块各自 throw new RuntimeException("超时")，监控系统无法区分是下游响应慢、本地线程池耗尽，还是缓存穿透，告警失焦；
- 资源泄漏被掩盖：Connection 或 Stream 未关闭本应由受检异常（如 IOException）强制提醒，但用 RuntimeException 包装后，开发者更易忽略 close() 调用，高并发下连接池迅速耗尽。
高并发场景下更有效的错误应对方式
把“不强制捕获”误当作“无需治理”，是常见误区。实际需构建分层防御：
- 入口强校验 + 快速失败：对用户输入、RPC 参数做白名单验证与范围检查，用 IllegalArgumentException 等非受检异常主动拦截非法请求，避免无效流量进入核心流程；
- 业务异常标准化封装：将所有可预期失败（库存不足、余额不够、权限拒绝）统一转为带 code/message 的业务异常对象，由网关统一格式化返回，前端/客户端可精准识别并引导用户操作；
- 关键路径异步解耦：支付成功后，不直接调用发票服务，而是发事件；发票服务失败可重试、补偿或人工介入，主交易链不受影响；
- 熔断与隔离落地：用 Resilience4j 或 Sentinel 对下游不稳定接口配置熔断阈值，当连续超时触发熔断时，直接返回兜底数据，而非让 RuntimeException 向上传导导致线程堆积。
什么时候该捕获非受检异常？
不是“能不能”，而是“该不该”。高并发系统中，仅在两类场景下合理捕获：
- 兜底防护层：全局 Filter 或 AOP 拦截器中捕获未处理的 RuntimeException，记录结构化日志、上报指标、返回 500 响应，并防止堆栈泄露敏感信息；
- 第三方 SDK 兼容性适配：调用未按契约设计的旧库时，其内部可能静默返回 null 或抛出模糊异常，此时需针对性捕获并转换为明确业务语义，而非放任穿透。
高并发系统的健壮性，不取决于异常类型是否“受检”，而取决于你是否把每一次失败都当作可定义、可观察、可恢复的业务状态来对待。
