try-catch-finally是保障消息队列“至少一次”语义与资源安全的核心结构：try内执行业务处理并禁止提前return，catch按异常类型区分重试或死信，finally统一管控ack/nack及资源释放，优先使用try-with-resources管理autocloseable资源。
在消息队列消费场景中，try-catch-finally不是兜底写法，而是保障“至少一次”语义与资源安全的核心控制结构。关键不在捕获异常，而在明确每段代码的职责边界：try做业务处理、catch做错误响应、finally做状态收尾——三者缺一不可。
消费逻辑必须包裹在try中，且不能提前return
消费者从队列拉取消息后，业务处理（如落库、调用下游、发通知）必须严格放在try块内。一旦处理中途抛异常，JVM会立即中断执行并跳转到catch，避免消息被“静默丢失”或“重复提交”。尤其注意：
- 不要在try里直接return业务结果，否则finally可能无法触发消息确认逻辑
- 若使用手动ack（如RabbitMQ的channel.basicAck），确认操作不能放在try末尾，而应交由finally统一控制
- 避免在try中做耗时操作（如大文件IO、长链路HTTP），否则可能触发消费超时，导致消息被重投
catch要区分异常类型，决定是否重试或死信
不同异常代表不同失败性质，不能一概而论地记录日志后吞掉：
- 瞬时异常（如ConnectException、TimeoutException）：适合有限重试（配合指数退避），不立即进死信队列
- 业务校验异常（如参数非法、状态冲突）：属于不可恢复错误，应直接拒绝（nack+requeue=false），进入死信流程
- 系统级异常（如OutOfMemoryError）：不应捕获，让进程崩溃并由容器重启，避免状态污染
finally负责消息生命周期的最终裁定
无论成功、失败还是中途退出，finally是唯一能确保消息被明确处置的位置：
- 成功场景：调用ack，确认消息已处理完毕
- 失败但可重试：不ack，也不nack，依赖消费者自动重入队（需配置autoAck=false）
- 失败且不可重试：执行nack（requeue=false），推动消息进DLX
- 务必检查连接/通道是否仍有效，避免在finally中调用已关闭资源的ack方法而引发新异常
替代方案：优先用try-with-resources管理客户端资源
如果消费逻辑涉及打开网络连接、文件句柄等AutoCloseable资源（如KafkaConsumer、RabbitMQ Channel），应优先使用try-with-resources语法：
- 它自动在离开作用域时调用close()，比手写finally更可靠
- 即使try或catch中抛出异常，close()仍会被执行，且异常会被压制（suppressed）而非覆盖主异常
- 注意：Kafka Consumer不建议在每次消费中新建，应复用实例；该语法更适合单次使用的资源，如临时解析JSON的JsonParser
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
