在RocketMQ中，未捕获的RuntimeException或Error会默认触发RECONSUME_LATER延迟重试，但Checked Exception需包装为RuntimeException；显式返回RECONSUME_LATER更可靠，且重试受最大次数（默认16次）和延迟级别控制。
在 RocketMQ 的 MessageListenerConcurrently 监听器中，throw 异常本身不会自动触发 ConsumeConcurrentlyStatus.RECONSUME_LATER；RocketMQ 默认会将未捕获的异常视为消费失败，并**自动返回 RECONSUME_LATER**（前提是未显式返回状态）。但这个行为有前提和细节需要注意。
默认抛异常即重试（但需满足条件）
RocketMQ 客户端在并发消费模式下，若监听器方法（consumeMessage）执行过程中抛出**未被捕获的运行时异常（RuntimeException）或 Error**，且方法返回值为 null（即没显式 return），则客户端内部会捕获该异常，并默认按 RECONSUME_LATER 处理 —— 也就是延迟重试（走重试队列）。
- ✅ 有效：直接
throw new RuntimeException("处理失败") - ✅ 有效：调用可能抛异常的方法（如
Objects.requireNonNull(null)）且不 try-catch - ❌ 无效：抛出
Exception子类但非 RuntimeException（如IOException），且方法声明未 throws 它 → 编译不通过（Java 检查异常必须处理） - ❌ 无效：自己 try-catch 了异常却没 re-throw，也未 return 状态 → 默认返回
CONSUME_SUCCESS，消息被确认消费
显式返回 RECONSUME_LATER 更清晰可靠
比起依赖隐式异常机制，更推荐在业务逻辑中主动判断并 显式 return ConsumeConcurrentlyStatus.RECONSUME_LATER。这样语义明确、可控性强，且不受异常类型限制。
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
- 可在 catch 块中处理特定异常后决定重试：
catch (TimeoutException e) { log.warn("调用下游超时，稍后重试", e); return ConsumeConcurrentlyStatus.RECONSUME_LATER; } - 可基于业务条件返回，比如库存不足、幂等校验失败等临时性问题
- 避免因误捕获异常或吞掉异常导致消息“假成功”
注意重试机制的实际表现
返回 RECONSUME_LATER 并不等于立刻重试。RocketMQ 会将消息投递到重试主题（%RETRY%xxx），按重试次数（默认最多 16 次）和延迟级别（如第 1 次延时 10s，第 2 次 30s…）逐步拉长间隔。超过最大重试次数后，消息进入死信队列（DLQ）。
立即学习“Java免费学习笔记（深入）”；
- 重试次数由消费者 Group 配置：
consumer.setMaxReconsumeTimes(16)（默认值） - 延迟级别对应时间由 Broker 配置
messageDelayLevel决定（如 “1s 5s 10s … 2h”） - 同一消息重试期间，Consumer 实例可能收到不同重试版本的消息（topic 不同），需注意幂等
不要 throw 检查异常（Checked Exception）除非声明 throws
MessageListenerConcurrently.consumeMessage 方法签名不声明抛出任何检查异常，因此不能直接 throw IOException、SQLException 等。否则编译报错。
- 正确做法：将检查异常包装为
RuntimeException后抛出，例如throw new RuntimeException(e); - 或更规范地：使用业务自定义运行时异常，如
throw new BizRetryException("DB 写入失败", e); - 不建议在方法签名加
throws Exception（接口不允许修改）
