not_supported与supports在无事务时行为相同，但语义迥异：not_supported主动挂起现有事务、独立执行且不受回滚影响；supports则依附现有事务或非事务运行，回滚时一并撤销。
NOT_SUPPORTED 和 SUPPORTS 在“当前没有事务”的情况下，表现看起来一样：都以非事务方式运行。但它们的语义、设计意图和潜在风险完全不同。
NOT_SUPPORTED：明确拒绝事务，主动挂起已有事务
它的核心是“不参与事务”。哪怕调用方正处在事务中，它也会把那个事务临时挂起，自己坚决用非事务方式执行。
- 适合写日志、发消息、调用第三方通知接口等不能受上游事务影响的操作
- 如果上游有事务，NOT_SUPPORTED 方法执行期间，上游事务处于暂停状态（挂起），等它结束后再恢复
- 即使上游回滚，NOT_SUPPORTED 中已提交的数据不会回滚——因为它根本不在那个事务里
SUPPORTS：随遇而安，有就用，没有也不强求
它不主动争取事务，也不排斥事务。只做一件事：当前有事务就加入，没有就安静地非事务运行。
Java JDK 25
下载
Java JDK 25 来自 OpenJDK 官方归档，版本为 JDK 25，本条下载地址已指向官方 Windows x64 zip 安装包直链，适合调试旧项目或兼容旧版 Java 运行环境。
- 适合查询类方法（如 getXXX、countXXX），既不需要强制事务，也不怕被卷入事务
- 如果上游无事务，它就纯读库、不开启事务，性能轻量
- 如果上游有事务，它就共享那个事务上下文——意味着上游回滚时，它所有 DML 操作（如果有）也会一并回滚
关键区别不在“无事务时”，而在“有事务时”
两者在外部没事务时确实行为一致，但真正差异体现在嵌套调用场景：
- serviceA（@Transactional） → serviceB（SUPPORTS）：serviceB 运行在 serviceA 的事务中，共进退
- serviceA（@Transactional） → serviceB（NOT_SUPPORTED）：serviceA 事务被挂起，serviceB 独立执行，serviceA 后续继续执行时才恢复事务
选错可能引发数据一致性问题
比如一个统计更新操作，本意是“无论主流程成不成功，计数都要加一”，若误用 SUPPORTS，主事务失败会导致计数也被回滚；而正确用 NOT_SUPPORTED，就能确保计数独立落地。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
