Java NIO框架可通过分层设计在关键入口统一处理异常：Netty用pipeline末尾的ExceptionCaughtHandler捕获未处理异常；Vert.x通过Router.failureHandler集中拦截；原生NIO需在select循环内手动try-catch并交由中心化处理器处理。
Java NIO 框架（如 Netty、Vert.x 或原生 NIO）本身不提供类似 Spring MVC 的全局异常拦截器机制，但可以通过分层设计 + 责任链思想，在关键入口处统一捕获和处理异常。核心思路是：把异常处理逻辑下沉到事件循环/ChannelHandler/Handler 的统一出口，避免每个业务 handler 重复 try-catch。
Netty 中基于 ChannelHandler 的统一异常拦截
Netty 是最典型的 NIO 框架，推荐在 pipeline 末尾添加一个自定义 ExceptionCaughtHandler，它会捕获上游所有 handler 抛出的未捕获异常（包括 decode 失败、业务逻辑异常、序列化错误等）：
- 继承
ChannelInboundHandlerAdapter，重写exceptionCaught(ChannelHandlerContext ctx, Throwable cause) - 该方法会被自动调用——只要上游 handler 没有显式 catch 并 consume 异常
- 在此统一记录日志、发送告警、关闭连接（视情况）、返回错误响应（如 HTTP 500 或自定义协议错误包）
示例：
public class GlobalExceptionHandler extends ChannelInboundHandlerAdapter {
@Override
public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) {
// 1. 日志记录（建议包含 channel ID、远程地址、堆栈）
logger.error("Exception in channel [{}] from [{}]",
ctx.channel().id(), ctx.channel().remoteAddress(), cause);
<pre class="brush:php;toolbar:false;"> // 2. 区分异常类型做不同处理
if (cause instanceof IOException) {
ctx.close(); // 连接异常，直接断开
} else if (cause instanceof BusinessException) {
writeErrorResponse(ctx, ((BusinessException) cause).getCode(), "业务失败");
} else {
writeErrorResponse(ctx, 500, "服务内部错误");
}
}
}
立即学习“Java免费学习笔记（深入）”；
注意：务必调用 ctx.fireExceptionCaught(cause) 向后传播（如果需要），或明确终止（如已响应错误）；否则可能掩盖问题。
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
Vert.x 中通过 Router 和 Failure Handler 统一拦截
Vert.x Web 基于 Event Loop，异常默认会中断路由链。可通过以下方式集中处理：
- 为
Router添加failureHandler：捕获所有RoutingContext.fail()触发的异常（含 4xx/5xx 主动抛出） - 在
HttpServerRequest.handler或SocketHandler外层包裹 try-catch（适用于底层 TCP/UDP 场景） - 使用
Vertx.exceptionHandler()捕获未被路由/Handler 消费的顶层异常（慎用，范围太广）
推荐做法是：业务中主动调用 routingContext.fail(500, ex)，再由 router.failureHandler() 统一渲染错误页或 JSON 错误响应。
自建 NIO 服务器（Selector + Channel）中的异常兜底
若直接使用 JDK NIO（Selector、SocketChannel），异常不会自动传播，需手动在事件循环中捕获：
- 在
while (selector.select() > 0)循环内，对每个SelectionKey的处理逻辑用 try-catch 包裹 - 将异常交给一个中心化的
ExceptionHandler实例处理（可单例 + SPI 扩展） - 特别注意：
OP_READ中的read()返回 -1（对端关闭）不是异常，而IOException（如 connection reset）才是需拦截的异常
关键点：不要让异常跳出 select() 循环，否则事件循环终止，整个服务不可用。
异常分类与响应策略建议
统一拦截后，应按异常性质差异化响应，避免暴露敏感信息：
- 连接层异常（IOException、ClosedChannelException）→ 记录并静默关闭 channel
- 协议解析异常（DecoderException、JsonProcessingException）→ 返回 400 Bad Request，不打印完整堆栈给客户端
- 业务异常（自定义 BusinessException）→ 映射为标准错误码 + 可读消息，保留 traceId 便于排查
- 系统异常（NullPointerException、OutOfMemoryError）→ 记录严重日志，触发熔断或告警，返回通用 500
不复杂但容易忽略：所有异常拦截器都应避免阻塞事件线程（如同步调用慢日志系统），必要时提交到独立线程池异步处理。
