在 spring cloud aws 中，通过 `@sqslistener` 的 `deletionpolicy = on_success` 配合显式异常抛出，可实现仅对指定自定义异常（如 `mycustomexception`）触发消息重试，其余异常被静默捕获，避免意外丢消息。
在使用 AWS SQS 与 Spring Cloud AWS 集成时，@SqsListener 默认行为是：只要方法执行完成（无论是否抛出异常），消息即被删除（除非显式配置 deletionPolicy）。而 SqsMessageDeletionPolicy.ON_SUCCESS 表示：仅当方法正常返回（无异常）时才自动删除消息；一旦抛出任何未捕获的异常，SQS 将保留消息并根据队列的 Visibility Timeout 和 Redrive Policy 进行重试或死信投递。
但默认情况下，所有未捕获的 RuntimeException 或 Exception 都会触发重试——这往往不符合业务需求。例如，你只希望在业务校验失败（如 MyCustomException）时重试，而对 NullPointerException、IllegalArgumentException 等编程错误或非法输入应立即记录告警、不重试、不阻塞队列，甚至可选择主动删除消息或转入死信队列（DLQ）。
✅ 正确做法是：用 try-catch 主动拦截所有异常，并有选择地重新抛出目标异常：
@SqsListener(
value = "https://sqs.us-east-1.amazonaws.com/123456789012/MyQueueURL",
deletionPolicy = SqsMessageDeletionPolicy.ON_SUCCESS
)
public void getMessageFromSqs(MyMessage message) {
try {
log.info("Processing message: {}", message);
if (someCondition(message)) {
throw new MyCustomException("Business validation failed — retry required");
}
// ✅ 正常处理完成，ON_SUCCESS 触发自动删除
log.info("Message processed successfully");
} catch (MyCustomException e) {
log.warn("Custom exception encountered, allowing retry", e);
throw e; // ? 关键：仅此异常透出，触发 SQS 重试机制
} catch (Exception e) {
// ? 其他所有异常（NPE、IO、JSON 解析失败等）均被吞掉
// 注意：此时方法“静默成功返回”，ON_SUCCESS 生效 → 消息被删除！
log.error("Unexpected error — message will be deleted (not retried)", e);
// 可选：在此处主动发送告警、记录到审计表、或调用 SQS deleteMessage（需 accessKey）
}
}⚠️ 重要注意事项：
- ON_SUCCESS 不等于“零丢失”：它仅保证 成功路径 删除消息；但若因 JVM 崩溃、容器重启等导致方法未返回，消息仍会因 Visibility Timeout 超时而重回队列（这是 SQS 自身保障机制）。
- 吞掉异常 ≠ 安全：catch(Exception) 吞掉非自定义异常虽防止了无效重试，但也掩盖了潜在 Bug。务必配合完善的日志、监控（如 Prometheus + Grafana）、错误追踪（如 Sentry）和告警。
- 避免空 catch 块：示例中 catch(Exception) 内必须包含明确的日志级别（error）和上下文，禁止 catch(Exception e) {}。
- 考虑 DLQ 最佳实践：对于反复失败的 MyCustomException（如连续 3 次），建议配置 SQS Redrive Policy 指向 DLQ，便于人工介入分析，而非无限循环重试。
- Spring Cloud AWS 版本兼容性：确保使用 spring-cloud-aws-messaging:2.4+ 或 spring-cloud-aws-starter-sqs:3.0+，旧版本 API（如 SqsMessageDeletionPolicy 枚举位置）可能存在差异。
总结：精准控制 SQS 重试的核心在于 “异常分类治理” —— 用 try-catch 显式区分业务可重试异常与系统不可重试异常，并严格匹配 deletionPolicy 行为。这既保障了业务语义的准确性，又避免了因泛化异常处理导致的消息堆积或数据丢失风险。
