Java异常暴露需分层设计：业务异常（如InsufficientBalanceException）应继承RuntimeException，通过API文档明确定义，Controller层转为400等HTTP状态码+结构化JSON；系统异常须收敛处理，记录ERROR日志并降级为泛化提示；中间层避免静默吞异常；暴露核心是提供决策信息而非实现细节。
Java异常是否应让调用方感知，取决于异常类型、所处层级和业务语义——不是“该不该暴露”，而是“以什么形式、在什么位置、向谁暴露”。
业务异常必须主动暴露给调用方
自定义的业务异常（如 InsufficientBalanceException、OrderAlreadyPaidException）本质是业务流程的一部分，不是错误，而是明确的状态反馈。这类异常应当：
- 继承 RuntimeException，不强制上层处理，但需在 API 文档或返回体中明确定义
- 携带标准错误码、用户友好的提示消息、可选的扩展字段（如跳转链接、重试建议）
- 在 Controller 层统一拦截，转为 HTTP 状态码（如 400）+ 结构化 JSON 响应，而非堆栈信息
系统异常要收敛后再暴露
运行时异常（NullPointerException、IllegalArgumentException）或受检异常（SQLException、IOException）一旦逃逸到 Controller 层，说明程序存在缺陷或外部依赖失联。此时不应原样抛给前端，而应：
- 记录 ERROR 日志，包含请求 URL、用户 ID、关键参数、完整堆栈
- 统一降级为泛化提示，例如 “服务暂时不可用，请稍后重试”
- 避免返回原始异常类名、文件路径、数据库表名等敏感信息
中间层通常不自行捕获并吞掉异常
Repository 和 Service 层一般不建议用 try-catch “静默消化”异常：
立即学习“Java免费学习笔记（深入）”；
- Repository 层抛出的 DataAccessException 或其子类，应直接向上透传，便于 Service 层判断是否重试或降级
- Service 层若涉及事务，捕获异常却未抛出会导致 @Transactional 失效，事务无法回滚
- 真正需要拦截的，是明确可恢复的场景（如缓存穿透时查 DB 失败，自动 fallback 到默认值）
暴露 ≠ 打印堆栈，也不等于返回全部细节
对调用方暴露异常的核心原则是：提供足够决策信息，但不泄露实现细节。
- 对外 API：只返回错误码 + 简洁提示 + 请求 traceId（用于查日志）
- 内部微服务调用：可额外传递业务上下文（如订单 ID、支付渠道），方便链路追踪
- 开发环境可开启详细堆栈；生产环境必须关闭，靠日志系统支撑排查
基本上就这些。暴露策略不是技术限制问题，而是接口契约和用户体验的设计选择。
