java未捕获异常需通过全局处理器（thread.setdefaultuncaughtexceptionhandler）和框架层（@controlleradvice）建立可控兜底机制，记录带trace id的完整日志、返回脱敏提示，避免掩盖致命错误或破坏线程状态。
Java 中未捕获的系统异常（如 NullPointerException、OutOfMemoryError）不会自动进入业务逻辑的 try-catch 流程，若不干预，会直接导致线程中断、应用崩溃或返回原始堆栈给前端——这既不安全也不友好。关键不是“拦截所有异常”，而是建立一层**可控兜底机制**，在异常逃逸到 JVM 之前完成日志记录、上下文保留和用户级提示转换。
设置全局未捕获异常处理器
通过 Thread.setDefaultUncaughtExceptionHandler 捕获主线程和后台线程中漏掉的异常：
- 仅对
Throwable子类生效，但应避开Error中的致命错误（如OutOfMemoryError），避免掩盖系统级风险 - 处理器内必须记录完整堆栈（
logger.error("全局异常", e)），并附加关键上下文：当前用户 ID、请求路径、时间戳 - 禁止在此处调用
System.exit()或强制关闭 GUI 线程，Swing/JavaFX 应使用SwingUtilities.invokeLater安全弹窗
统一异常转换入口（推荐 Controller 层或 Filter）
在 Web 应用中，更稳妥的做法是让异常上升至框架能接管的位置，例如 Spring 的 @ControllerAdvice：
- 用
@ExceptionHandler(Exception.class)捕获未被业务代码处理的异常，但需放在所有具体异常 handler 之后（顺序从具体到宽泛） - 对
RuntimeException和Error分开处理：前者可尝试提取业务码，后者直接返回500 Internal Server Error+ 固定提示 - 响应体只含错误码（如
"system.unexpected"）和脱敏提示（如“服务暂时不可用”），绝不包含stackTrace、cause字段
为未知异常生成 trace ID 并关联日志
用户看到的提示必须稳定、简洁，而排查线索要完整、可追溯：
- 每次捕获未知异常时，生成唯一 trace ID（如
UUID.randomUUID().toString().substring(0, 8)） - 将 trace ID 同时写入日志（ERROR 级别）和响应头（如
X-Trace-ID），方便前后端联查 - 前端在提示语末尾显示该 ID（如“服务异常，请联系客服并提供编号 abcd1234”），既不暴露技术细节，又提供有效反馈锚点
避免常见陷阱
兜底机制失效往往源于几个隐蔽错误：
- 在
finally块中抛出新异常，覆盖原始异常，导致根本原因丢失 - 用
catch (Exception e)包裹整个方法体，却只记录日志不 re-throw，使调用方误以为操作成功 - 消息码硬编码在 catch 块里，无法支持多语言或热更新；应通过
MessageSource或配置中心动态加载 - 对
InterruptedException简单吞掉或忽略恢复中断状态（Thread.currentThread().interrupt()），影响线程池稳定性
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
