本文详解 spring @retryable 注解在单元测试中“看似不生效”的根本原因，指出 ide 调试干扰、代理机制误用及测试设计缺陷等关键陷阱，并提供可落地的验证方案与完整测试代码示例。
Spring 的 @Retryable 是一个基于 AOP 的声明式重试机制，其核心依赖 Spring 的代理（Proxy）——只有通过 Spring 容器管理的 Bean 间跨 Bean 调用，且目标方法被 @Retryable 标注时，重试逻辑才会被织入。这正是许多开发者测试失败的首要根源：直接调用、私有方法、同一类内自调用或非 Spring 管理对象调用，均会导致 @Retryable 完全静默失效。
在你的案例中，MyServiceImpl 调用 myAccessor.accessorMethod(...) 看似满足“跨 Bean”条件，但问题往往隐藏于细节：
-
Bean 代理未启用或配置缺失：仅 @EnableRetry 不够，必须确保 myAccessor 实际是 Spring 容器中由 @Retryable 增强后的代理 Bean。若 test-config.xml 中未正确声明
proxy />（XML 配置）或缺少 @EnableAspectJAutoProxy（Java 配置），则 @Retryable 切面不会生效； - 异常类型不匹配：@Retryable(include = {...}) 仅对显式抛出的指定异常类型重试。你代码中捕获了 UncategorizedSQLException 后又 throw exception;，看似合理，但若该异常在运行时实际为子类（如 SQLTimeoutException），而未包含在 include 列表中，则不会触发重试；
- IDE 调试干扰（关键！）：正如答案所揭示，这是最易被忽视的“伪失败”。当在 IDE（如 IntelliJ IDEA）中以 Debug 模式 运行测试并设置断点时，首次异常抛出即被调试器捕获并中断，导致后续重试逻辑无法执行——此时控制台日志、监听器回调均不会出现，给人“完全没重试”的错觉。而切换为 Run 模式 后，重试会正常进行。
✅ 正确验证方式如下（推荐使用 Spring Boot Test）：
@SpringBootTest
@EnableRetry
class MyServiceTest {
@Autowired
private MyService myService;
@Autowired
private MyAccessor myAccessor; // 确保是容器注入的代理实例
@Test
void serviceMethodRetryTest() {
// 使用 Mockito 模拟 accessorMethod 抛出异常两次，第三次成功
doThrow(new UncategorizedSQLException("test", "sql", new SQLException()))
.doThrow(new UncategorizedSQLException("test", "sql", new SQLException()))
.doReturn("success")
.when(myAccessor).accessorMethod(anyString());
String result = myService.serviceMethod("test-param");
assertThat(result).isEqualTo("success");
// 验证 accessorMethod 被调用了 3 次（2次失败 + 1次成功）
verify(myAccessor, times(3)).accessorMethod("test-param");
}
}⚠️ 注意事项：
- 永远避免在 Debug 模式下验证重试行为，改用 Run 模式 + 日志/监听器确认；
- 在 @Retryable 方法中，不要 catch 并吞掉需重试的异常（如你代码中的 catch (Exception) { return null; }），否则重试机制失去触发点；
- 自定义 RetryListener 是验证重试过程的利器，务必实现 onError() 和 close() 方法并打印日志；
- 若使用 XML 配置，确保 test-config.xml 包含：
总结：@Retryable 的“失效”极少源于 Spring 本身缺陷，绝大多数情况是代理未生效、异常未穿透、或测试方式不当所致。掌握代理机制本质、规避 IDE 调试陷阱、结合 Mock 与监听器验证，即可精准掌控重试行为。
