网络抖动与字段永久不合法，都可能让消费失败，但处理方式不同。把所有异常无限重试，会浪费资源并掩盖真正需要修复的数据。重试策略要与业务期限和恢复方式绑定。
先分类失败原因
暂时依赖不可用可以考虑受限重试；权限、契约或业务状态问题需要判断是否可恢复。分类也可能不完全准确，因此保留错误摘要和尝试记录，让后续处理有证据。
给重试设置间隔和终点
确定次数、延迟、总等待范围及超限出口。对已产生副作用的处理，重试前必须保证幂等。多层各自重试还可能放大次数，需要明确责任边界。
隔离不是丢弃
进入死信或异常队列后，应有负责人、告警和查询方式。记录修复后如何选择性重放，以及哪些业务需要人工确认。无人维护的死信队列只是把失败藏到另一个位置。
验收永久错误与恢复
构造一条始终不合法的消息，确认它不会阻塞其他业务；再恢复暂时依赖，检查可恢复任务按规则完成。观察顺序、重复与下游压力。
常见问题：重试次数能统一设成三次吗？
可以作为某类操作的约定，但没有通用最优次数，应根据业务影响、幂等能力和依赖特点验证。
技术参考：RabbitMQ：发布与消费确认。具体接口与配置请结合使用版本核对。
将评估落实到你的系统
如果你的 .NET 应用还缺少可重复的部署、观察或恢复流程，可以通过容器化与自动化交付服务梳理现状，约定实施内容、演练场景与运维交接方式。