spring boot异常处理应分层：repository层只抛技术异常（如sql异常），service层封装业务异常并决策回滚/重试，controller层仅用@restcontrolleradvice统一包装响应，不处理业务逻辑。
异常处理不能堆在一处，分层处理才能让系统既健壮又清晰。Web 层只管“怎么告诉用户”，服务层专注“业务是否成立”，持久层守住“数据操作是否成功”——三层各守一关，不越界、不遗漏。
Web 层（Controller/API 层）：只做响应包装，不碰业务判断
这一层是异常的“出口守门人”，职责非常明确：接收底层抛出的异常，转换为用户能理解的格式（如 HTTP 状态码 + JSON 错误体），不参与校验逻辑或重试决策。
- 统一用 @RestControllerAdvice 拦截全局异常，避免每个 Controller 重复写 try-catch
- 对参数校验失败（MethodArgumentNotValidException）、路径不存在（NoHandlerFoundException）等框架级异常，直接映射为 400 或 404 响应
- 遇到自定义业务异常（如 BusinessException），提取 message 并返回 400 或 500，视语义而定；不打印堆栈给前端
- 绝不在 Controller 里捕获 SQLException、NullPointerException 等底层异常并自行“消化”——这会掩盖问题根源
服务层（Service 层）：封装异常语义，主导事务边界与业务补偿
这是异常处理的“中枢决策点”。它要识别哪些错误属于业务规则不满足（如余额不足、状态非法），哪些是系统不稳定（如远程调用超时），并决定是否回滚、重试或降级。
- 对 DAO 层抛出的持久化异常（如 PersistenceException、DataAccessException），不直接向上抛，而是包装为语义明确的自定义异常（如 InsufficientStockException、UserLockedException）
- 在 @Transactional 方法内，非受检异常（RuntimeException 及其子类）默认触发回滚；若需对特定受检异常也回滚，显式声明 @Transactional(rollbackFor = XxxException.class)
- 涉及多个资源协作（如扣库存 + 发消息），用 try-catch 捕获局部异常后，主动执行补偿逻辑（如反向加回库存），再抛出统一业务异常
- 不处理日志细节——只抛异常；具体错误日志由 AOP 或全局处理器统一记录
持久层（DAO/Repository 层）：只反映数据操作结果，不解释原因
这一层是异常的“源头传感器”。它不做翻译、不加修饰，把数据库或 ORM 框架的真实反馈原样暴露出来，交由上层判断含义。
- MyBatis 映射失败、SQL 语法错误、主键冲突、连接超时等，统一由框架抛出对应异常（如 SQLSyntaxErrorException、SQLIntegrityConstraintViolationException），DAO 方法不 catch 也不吞掉
- 不自己 new Exception("查询失败") —— 这种模糊异常丢失了原始上下文，让服务层无法区分是超时还是字段不存在
- 可对部分底层异常做轻量适配，例如将 Hibernate 的 ConstraintViolationException 转为 Spring 的 DataIntegrityViolationException，保持异常体系与 Spring 生态对齐
- 不记录日志——异常尚未被语义化，此时打日志容易污染错误追踪链路
分层异常处理不是增加代码量，而是让每类错误在最合适的环节被识别、转化和响应。越底层越具体，越上层越抽象；异常流经的路径，就是业务语义逐步浮现的过程。
