businessexception抛出后逻辑未中断，通常因异常被try-catch吞没或未继承runtimeexception；spring仅对未检查异常自动事务回滚和全局拦截，需确保其继承自runtimeexception、调用链无静默捕获、@exceptionhandler明确声明且@transactional配置rollbackfor。
throw BusinessException 时为什么逻辑没中断？
常见现象是写了 throw new BusinessException("参数错误")，但后续代码仍执行——多半因为抛出点被 try-catch 吞掉了，或者 BusinessExeption 没继承 RuntimeException。Spring 默认只对未检查异常（即继承 RuntimeException）做事务回滚和全局异常拦截，如果 BusinessException 是 Exception 的子类，throw 后虽能抛出，但可能被上层静默捕获，或事务不回滚。
实操建议：
- 确认
BusinessException继承自RuntimeException，而非Exception - 检查调用链中是否存在无意识的
try { ... } catch (Exception e) { ... }，尤其在工具类或 AOP 切面里 - 若用 Spring Boot，确保
@ControllerAdvice中的@ExceptionHandler明确声明了BusinessException.class
在 Service 层 throw 的典型位置和参数设计
不是所有校验都适合 throw。重点放在「业务规则不可绕过」的节点：比如重复提交、状态非法变更、权限越界、余额不足。这时 throw 不是报错，而是明确拒绝并终止流程。
实操建议：
- 避免在 DTO 转 VO 或简单字段判空时 throw，优先用
Assert.notNull()或 JSR-303 注解 - 构造
BusinessException时传入可定位的错误码，如new BusinessException("USER_STATUS_INVALID", "用户状态不允许执行此操作") - 不要在循环内频繁 throw，除非每次都是独立业务单元；否则考虑收集错误后统一抛出
throw 后事务不回滚？检查这三点
即使 throw 成功，Service 方法加了 @Transactional，事务也可能没回滚——这不是 throw 的问题，而是传播机制或异常类型不匹配。
实操建议：
- 确认方法是 public，且被 Spring 容器管理（非 this.xxx() 直接调用）
- 检查
@Transactional的rollbackFor属性是否包含BusinessException.class，例如：@Transactional(rollbackFor = BusinessException.class) - 若 BusinessException 是 RuntimeException 子类，但仍有不回滚，可能是事务代理失效，用
@EnableAspectJAutoProxy(exposeProxy = true)并通过AopContext.currentProxy()调用
前端拿不到具体错误信息？别让 BusinessException 被二次包装
常见坑是全局异常处理器里把 BusinessException 包装成通用 Result.fail()，但错误码/消息被覆盖或转成了模糊提示（如“操作失败”），导致前端无法做差异化处理。
实操建议：
- 在
@ExceptionHandler(BusinessException.class)方法中，直接取e.getMessage()和自定义的getCode()字段，不要 toString() - 避免在 Controller 层再 catch BusinessException 做日志+rethrow，容易破坏异常原始堆栈和语义
- 如果 BusinessException 有分级（如警告级不中断流程），那就别 throw，改用返回值封装，
throw应代表「必须终止」
throw 在入口就卡住。最容易忽略的是异常类型继承关系和事务传播配置，这两处一错，throw 就变成无效的摆设。
