Java自定义异常不会触发分布式事务超时，仅用于响应超时、封装语义并驱动回滚；超时由事务管理器检测并控制，自定义异常需继承RuntimeException且不被静默捕获，才能被Spring/Seata识别为回滚依据。
Java 自定义异常本身不会自动触发分布式事务超时，它只是错误信息的载体。事务超时由事务管理器（如 Spring 的 @Transactional、Seata 的 @GlobalTransactional 或 Atomikos）在运行时检测并主动控制，而自定义异常的作用是在超时发生后，精准表达问题语义，并参与事务回滚决策。
要让自定义异常在分布式事务超时场景中“被触发”并有效起作用，关键在于将超时检测逻辑与异常抛出时机对齐，并确保该异常能被事务框架识别为回滚依据。以下是实际可行的路径：
明确超时责任归属：谁检测？谁抛？
分布式事务超时不是 JVM 主动抛出的异常，而是由事务协调者（TC）或本地事务管理器在预定时间未收到响应时作出的决策。例如：
- Spring
@Transactional(timeout = 30)：本地事务超时由TransactionInterceptor在方法执行超时后主动抛出TransactionTimedOutException； - Seata
@GlobalTransactional(timeout = 60)：全局事务超时由 TC 主动终止，并向各 RM 发送回滚指令，此时业务方法若仍在执行，需配合中断机制（如检查Thread.interrupted()）主动退出并抛出自定义异常； - Atomikos/XA：超时由 JTA 事务管理器触发，通常抛出
javax.transaction.TransactionRolledbackException等标准异常。
✅ 所以：你不能靠“抛出自定义异常”来引发超时，但可以靠它来响应超时、封装上下文、驱动补偿或记录审计。
立即学习“Java免费学习笔记（深入）”；
使用自定义异常承接超时结果
当检测到超时（例如远程调用卡住、分支事务迟迟未响应），应主动抛出带有业务含义的自定义异常，而非裸 throw RuntimeException。例如：
public class PaymentTimeoutException extends RuntimeException {
private final String orderId;
private final long elapsedMs;
public PaymentTimeoutException(String orderId, long elapsedMs) {
super("支付处理超时，订单ID：" + orderId + "，已耗时：" + elapsedMs + "ms");
this.orderId = orderId;
this.elapsedMs = elapsedMs;
}
// 可扩展：返回结构化错误码、支持序列化、集成监控埋点等
}在服务方法中配合超时控制使用：
@GlobalTransactional(timeout = 30) // Seata 全局事务超时设为 30 秒
public void processOrder(String orderId) {
try {
// 调用下游支付服务，设置 HTTP 客户端超时为 25 秒（留 5 秒缓冲）
paymentClient.pay(orderId).timeout(25, TimeUnit.SECONDS).block();
} catch (TimeoutException e) {
// 捕获客户端超时，转为业务语义明确的自定义异常
throw new PaymentTimeoutException(orderId, 25000);
}
}这样，当 paymentClient 超时，你主动抛出 PaymentTimeoutException，Seata 的全局事务拦截器会捕获它，默认触发全局回滚（前提是未配置 noRollbackFor）。
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
确保事务框架识别并回滚
Spring 和 Seata 默认只对 unchecked 异常（即 RuntimeException 及其子类） 回滚。因此你的自定义异常必须继承 RuntimeException，且不能被中间层静默吞掉：
-
❌ 错误写法（异常被捕获但未重抛）：
try { processOrder(orderId); } catch (PaymentTimeoutException e) { log.error("忽略超时，继续执行", e); // → 事务不会回滚！ } -
✅ 正确做法（让异常穿透到事务切面）：
@GlobalTransactional public void orchestrateFlow(String orderId) { inventoryService.reserve(orderId); // 分支1 paymentService.charge(orderId); // 分支2 → 可能抛 PaymentTimeoutException // 若 charge 抛出该异常，全局事务自动回滚所有分支 }
同时，可在注解中显式声明回滚策略（增强可读性）：
@GlobalTransactional(rollbackFor = PaymentTimeoutException.class)
public void processOrder(String orderId) { ... }补充：超时 + 重试 + 自定义异常的协同模式
在高可用设计中，超时常与重试结合。此时自定义异常还可携带重试上下文：
public class RetryableTimeoutException extends PaymentTimeoutException {
private final int retryCount;
public RetryableTimeoutException(String orderId, int retryCount) {
super(orderId, 25000);
this.retryCount = retryCount;
}
}再配合 @Retryable（Spring Retry）或 Seata 的重试机制，在有限次数内重试；达到阈值后抛出非重试型异常（如 FatalPaymentTimeoutException），强制终止流程并告警。
不复杂但容易忽略。
