Spring Boot @SqsListener消费SQS大负载时S3对象是否自动删除

@SqsListener本身不内置SQS大消息对应的S3对象生命周期管理能力，S3对象会不会自动删除，和这个注解没有直接关系，完全取决于你注入的SQS Extended Client配置。

• 你发送消息后没在S3桶看到对应对象，优先检查messageSizeThreshold配置：Extended Client默认只有消息体积超过256KB时才会把payload转存S3，小于阈值的消息会直接走SQS原生链路传输，根本不会写入S3，这是测试阶段最容易踩的坑。判断消息是否真的走了S3转存很简单，直接拉取SQS队列里的对应消息，如果消息体是带固定格式的S3资源指针，不是你发送的原始业务内容，才说明确实触发了大消息转存逻辑。
• 关于S3对象自动删除的逻辑：
  Extended Client自带deleteS3MessageOnReceipt配置项，这个配置默认是关闭的：
  • 如果你手动把这个配置设为true，只要客户端成功从S3拉取到消息payload，就会立刻触发S3对象删除，这个动作发生在消息拉取阶段，和你@SqsListener里的业务逻辑是否执行成功没有任何绑定，哪怕后续业务消费抛异常，S3上的对象也已经被删掉了
  • 如果你保持默认的false配置，不管你用不用@SqsListener，S3上的消息对象都不会被自动清理，必须手动编写删除逻辑，否则对象会一直留在桶里产生存储成本
• Spring环境集成的额外注意点：
  如果你用的是Spring Cloud AWS的SQS starter，2.x及更早版本默认没有集成Extended Client的自动配置，你需要自己手动注册包装了S3存储配置的Extended SQS Client Bean替换默认客户端，不然@SqsListener会把S3指针当普通消息体解析，直接报序列化错误。3.0+版本虽然提供了Extended Client的自动配置支持，但默认也不会开启S3对象自动删除，必须手动把配置项spring.cloud.aws.sqs.extended.delete-payload-on-receive设为true才会生效。

• 不要完全依赖客户端的自动删除逻辑，建议专门给存SQS大消息的S3桶配置生命周期过期规则，兜底清理残留对象，避免客户端异常、消费失败等场景下的无用存储消耗
• 如果业务要求S3对象必须在业务逻辑消费成功后才允许删除，不要开启拉取即删除的配置，应该在@SqsListener的业务逻辑执行成功后，手动调用Extended Client的删除接口清理对应S3对象，同时给SQS队列配置死信队列，兜底处理消费失败的消息，避免消息丢失。

内容的提问来源于stack exchange，提问作者OneNoOne