应精简异常信息：避免堆栈冗余，用语义化异常类和简洁消息；一次封装原则；日志记全栈、对外只返错误码+摘要；生产环境禁用debug堆栈；用traceid替代堆栈追踪。
Java异常信息过多，核心在于避免堆栈冗余、隐藏无关细节、突出关键错误原因。不是删减日志，而是让异常本身更精准、可读、易定位。
只抛出必要的异常类型和消息
不要在捕获后用new RuntimeException(e.getMessage())包装再抛，这会丢失原始异常类型和堆栈。应优先使用语义明确的受检/非受检异常类，并在构造时传入简洁、用户/开发者能直接理解的提示。
- 用IllegalArgumentException代替RuntimeException，消息写成"timeoutMs must be positive, got: -500"，而非"invalid parameter"
- 业务异常统一继承自BusinessException，消息聚焦“发生了什么+影响范围”，如"Order #ORD-789 cannot be canceled: already shipped"
- 日志中记录完整堆栈，但向调用方（如API响应）只返回精简错误码和一句话摘要
避免层层包装导致堆栈爆炸
常见反模式：A方法捕获异常 → 包装为新异常 → B方法再捕获 → 再包装 → C方法…最终堆栈200行。应遵循“一次封装”原则：只在边界处（如Controller、Service入口）做一次有意义的转换。
- 内部Service层抛出DataAccessException，含SQL和参数信息；Controller层捕获后转为ApiException(ErrorCode.DB_ERROR, "订单查询失败")，不带原始堆栈
- 使用Throwable.addSuppressed()替代重复throw，适用于资源关闭等次要异常补充
- 工具类如Apache Commons Lang的ExceptionUtils.getRootCause()可快速提取根本原因，跳过中间包装层
用错误码+结构化消息替代长文本
面向前端或跨系统调用时，异常信息应是机器可解析的。纯文本堆栈对前端无意义，还可能泄露敏感路径或变量名。
立即学习“Java免费学习笔记（深入）”；
- 定义统一错误响应体：{ "code": "ORDER_SHIPPED", "message": "订单已发货，不可取消", "requestId": "req_abc123" }
- 错误码全大写、语义化，不依赖消息文本判断逻辑；message仅作人眼提示，不用于程序分支
- 开发环境开启debug=true才返回完整堆栈，生产环境默认关闭
定制异常打印策略（高级）
若必须输出日志，可通过重写printStackTrace(PrintStream)或使用SLF4J的Marker机制控制输出粒度。
- 自定义异常类中覆盖getStackTrace()，过滤掉框架内部无关行（如Spring AOP、CGLIB代理层）
- 用MDC注入traceId，让日志搜索替代堆栈追踪：“查traceId=xxx的所有日志”比“翻150行堆栈”更高效
- 异步任务或定时任务中，捕获异常后主动截断堆栈（保留前5行），防止日志刷屏
