问题出现：
try-catch 语句 依旧会抛出如下错误
org.springframework.transaction.TransactionSystemException: Could not commit JPA transaction; nested exception is javax.persistence.RollbackException: Transaction marked as rollbackOnly
at org.springframework.orm.jpa.JpaTransactionManager.doCommit(JpaTransactionManager.java:526)
at org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:761)
at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:730)
at org.springframework.transaction.interceptor.TransactionAspectSupport.commitTransactionAfterReturning(TransactionAspectSupport.java:518)
at org.springframework.transaction.interceptor.TransactionAspectSupport.invokeWithinTransaction(TransactionAspectSupport.java:292)
at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:96)问题解决：
try-catch 为什么还会事务回滚
在编程中，使用 try-catch 语句块确实可以帮助你捕获和处理异常，但这并不直接影响数据库事务的提交或回滚。事务的提交或回滚通常是由事务管理器根据事务的边界和事务属性（如隔离级别、传播行为等）来控制的，而不是直接由 try-catch 语句块控制的。
然而，有几个原因可能导致在使用 try-catch 时事务仍然回滚：
-
未捕获的异常 ：如果事务中的代码抛出了未被
try-catch捕获的异常，那么这个异常将传播到事务的边界，导致事务管理器触发回滚操作。 -
运行时异常 ：在 Spring 等框架中，默认情况下，运行时异常（
RuntimeException及其子类）会导致事务回滚。即使你在try-catch中捕获了这些异常，如果没有显式地调用事务的提交方法（在大多数场景下，这是不必要的，因为框架会为你管理事务），事务管理器仍然会根据异常的类型和配置来决定是否回滚事务。 -
事务传播行为 ：如果你在一个已经存在的事务中开始了一个新的事务（例如，使用了 Spring 的
@Transactional注解，并且事务的传播行为是REQUIRED或其他允许嵌套事务的行为），那么内部事务的异常可能会影响到外部事务的状态，导致外部事务也回滚。这取决于具体的事务管理器和配置。 -
事务回滚的显式请求 ：在某些情况下，你的代码可能显式地请求了事务回滚，即使异常被捕获了。例如，在 Spring 中，你可以通过编程方式调用
TransactionStatus.setRollbackOnly()来标记事务需要回滚。 -
框架或容器的行为：使用的框架或容器（如 Spring、EJB 等）可能有自己的事务管理策略，这些策略可能会根据捕获的异常类型、事务的属性或其他因素来决定是否回滚事务。
-
数据库约束：即使你的代码中没有异常，数据库级别的约束（如主键冲突、外键约束等）也可能导致 SQL 语句执行失败，从而触发事务回滚。
因此，当你看到即使使用了 try-catch 事务仍然回滚时，你应该检查以下几点：
- 是否有未捕获的异常。
- 是否捕获了运行时异常但期望事务继续。
- 事务的传播行为和嵌套事务的处理方式。
- 是否有显式地请求事务回滚的代码。
- 数据库约束是否可能导致事务失败。
此外，了解你使用的框架或容器的事务管理策略和配置也是非常重要的。
捕获了运行时异常但期望事务继续
在大多数现代Java框架（如Spring）中，运行时异常（RuntimeException 及其子类）默认会导致事务回滚。这是因为运行时异常通常表示程序中的错误，这些错误可能破坏了数据的完整性或一致性，因此框架选择自动回滚事务以避免潜在的问题。
然而，如果你捕获了运行时异常但仍然希望事务继续（即不触发回滚），你需要采取一些额外的步骤来确保这一点。但是，请注意，这种做法通常是不推荐的，因为它可能隐藏了潜在的问题并导致数据不一致。
在Spring框架中，你可以通过以下几种方式来处理这个问题：
-
使用
@Transactional(noRollbackFor = ...)或@Transactional(noRollbackForClassName = ...)你可以在服务层的方法上使用
@Transactional注解，并通过noRollbackFor或noRollbackForClassName属性来指定哪些异常不应该导致事务回滚。但是，请注意这些属性只接受编译时异常（即那些继承自Exception但不继承自RuntimeException的异常）。对于运行时异常，你需要使用@Transactional(rollbackFor = Exception.class, noRollbackFor = YourSpecificRuntimeException.class)这样的组合，但实际上由于Exception.class已经包括了所有的异常，所以只需要noRollbackFor就足够了。但更常见的做法是将rollbackFor留空，仅使用noRollbackFor。然而，由于
noRollbackFor不直接支持运行时异常，你需要显式地列出不希望回滚的运行时异常类型。@Transactional(noRollbackFor = YourSpecificRuntimeException.class)
public void yourServiceMethod() {
try {
// 可能会抛出 YourSpecificRuntimeException 的代码
} catch (YourSpecificRuntimeException e) {
// 处理异常，但希望事务继续
// 注意：这里不会阻止事务回滚，因为@Transactional的noRollbackFor属性需要精确匹配
}
}
- 但是，由于Spring的
@Transactional注解在方法边界上处理事务，并且不直接检查方法体内部的异常处理逻辑，因此上述noRollbackFor的使用实际上是在说："如果这个方法抛出了YourSpecificRuntimeException，请不要回滚事务。" 它并不依赖于你是否在方法内部捕获了这个异常。
-
编程式事务管理
如果你需要更细粒度的控制，可以考虑使用编程式事务管理。这允许你在代码中显式地开始、提交或回滚事务。但是，这种方法更加复杂，并且通常不推荐用于服务层方法，因为它与声明式事务管理相比更加繁琐且容易出错。
-
重新考虑异常处理策略
最后，你可能需要重新考虑你的异常处理策略。通常，如果一个运行时异常表明数据可能已经处于不一致的状态，那么回滚事务是保护数据完整性的正确做法。如果你的业务逻辑允许在发生特定运行时异常时继续执行（尽管这很少见），你可能需要重新设计你的业务逻辑或异常处理逻辑，以确保数据的一致性和完整性不会受到影响。
总的来说，虽然你可以通过@Transactional注解的noRollbackFor属性来防止某些特定的运行时异常导致事务回滚，但通常建议仔细考虑是否真的需要这样做，并确保你的业务逻辑和数据完整性不会因此受到损害。
--end--