Seata回滚失败需捕获底层异常并透传上报：在RM端自定义DataSourceProxy和UndoLogManager拦截异常，通过全局事务切面监听onBranchRollbackFailed事件，结合关键配置（如report.success.enable=false）避免静默失败，并构建含xid、服务名、SQL片段等线索的可追溯告警。
当Seata分布式事务回滚失败时，异常往往被框架内部吞掉或转化为非预期状态（如GlobalTransactionException、RollbackFailureException），导致业务层难以感知。要实现精准告警，关键不是等“事务失败”结果，而是捕获回滚阶段抛出的原始异常并沿调用链向上透传、识别、上报。
捕获Seata回滚过程中的底层异常
Seata的AT模式在回滚时会执行undo逻辑，若SQL执行失败（如主键冲突、字段类型不匹配、连接超时），会抛出JDBC异常（如SQLException），但默认会被UndoLogManager或RMInboundHandler包装为BranchTransactionException或RuntimeException。需在RM端（即每个微服务的DataSource代理层）增强日志与异常拦截：
- 自定义
DataSourceProxy包装器，在branchRollback方法中try-catch所有异常，并记录完整堆栈 - 重写
io.seata.rm.datasource.undo.UndoLogManager#deleteUndoLog，在删除undo log失败时主动抛出带上下文信息的异常（如含xid、branchId、resourceId） - 启用Seata日志级别为
DEBUG，重点关注io.seata.rm.datasource和io.seata.rm.AbstractRMHandler包下的日志输出
在全局事务切面中统一拦截回滚异常
利用Seata提供的@GlobalTransactional注解本质是基于AOP实现，可在自定义切面中监听事务生命周期事件：
- 继承
GlobalTransactionScanner或监听GlobalTransactionEvent（需适配Seata 1.5+的事件总线机制） - 在
onBranchRollbackFailed事件回调中提取BranchRollbackResult，判断result.status == RollbackStatus.RollbackFailed且result.msg != null - 将异常信息（含xid、服务名、时间戳、原始cause）封装为告警对象，推送至监控系统（如Prometheus + AlertManager、SkyWalking告警通道、或企业微信/钉钉机器人）
避免异常被静默吞掉的关键配置
Seata默认对部分回滚失败场景做“尽力而为”处理，容易掩盖问题：
立即学习“Java免费学习笔记（深入）”；
- 关闭
client.rm.report.success.enable=false（默认true），防止RM误报回滚成功 - 设置
client.rm.report.retry.count=0，禁用失败后的重试上报，避免掩盖首次失败原因 - 在
seata-spring-cloud-starter中显式配置failureHandlerBean，实现io.seata.core.exception.TransactionExceptionCode对应异常的分类处理逻辑
构建可追溯的异常链告警内容
单纯告警“回滚失败”价值有限，需提供定位线索：
- 告警标题包含：
[Seata-Rollback-Fail] xid=${xid} service=${appName} branch=${branchId} - 告警正文至少包含：失败时间、TC地址、RM资源ID、原始异常类名（如
MySQLIntegrityConstraintViolationException）、SQL语句片段（脱敏后）、undo_log表中对应记录的log_status值 - 附加跳转链接：指向SkyWalking追踪ID、ELK中关联日志查询URL、或Seata Server控制台的xid详情页
不复杂但容易忽略的是：回滚异常往往发生在分支事务提交之后，此时全局事务已标记为CommitFailed或RollbackFailed，但业务代码可能早已返回HTTP 200。必须跳出“只看Controller返回码”的惯性，真正把RM侧的失败信号捕获并放大。
