.NET代码中如何检测Azure Queue消息的插入状态

核心校验逻辑（无需额外请求） #

直接使用Azure.Storage.Queues官方SDK内置的操作回执做状态判定，这是官方设计的最高效校验路径，完全替代前后两次消息计数对比的方案：

• 调用SendMessageAsync方法投递消息时，SDK会等待Azure Queue服务端完成消息持久化、返回成功响应后，才将结果交付给调用方
• 若方法执行过程中未抛出异常，且成功获取到SendReceipt类型的返回对象，即代表消息插入成功。SendReceipt中存储的MessageId、InsertionTime、ExpiresOn字段可直接作为操作成功的凭证留存日志
• 所有插入失败的场景（包括权限不足、队列不存在、消息大小超限、服务端5xx错误、网络超时），SDK会统一抛出携带具体错误码的RequestFailedException，通过捕获该异常即可直接标记插入失败状态，无需事后反向校验

示例代码 #

// 初始化队列客户端
QueueClient queueClient = new QueueClient(connectionString, queueName);
try
{
    // 发送消息并获取服务端回执
    SendReceipt receipt = await queueClient.SendMessageAsync(
        messageContent: "待投递的消息内容",
        timeToLive: TimeSpan.FromDays(7));
    
    // 无异常即代表插入成功
    Console.WriteLine($"消息插入成功，消息唯一ID：{receipt.MessageId}");
}
catch (RequestFailedException ex)
{
    // 捕获失败状态，记录错误码便于定位
    Console.WriteLine($"消息插入失败，错误码：{ex.ErrorCode}，详情：{ex.Message}");
}

原有计数对比方案的固有缺陷 #

• 额外网络开销冗余：单次插入操作原本仅需1次REST请求，前后两次计数校验会增加2次额外请求，拉高接口整体延迟与调用成本
• 校验准确性不足：队列的消息计数接口存在最终一致性窗口，数值更新有短暂延迟；高并发场景下如果有其他生产者、消费者同时操作队列，两次计数的差值会被其他操作干扰，无法准确对应本次插入的消息状态
• 故障定位能力弱：即使计数无增长，也无法区分是插入请求未到达服务端、服务端校验拒绝、还是计数接口返回了旧值，无法快速定位问题根因

高可靠场景的增强校验方案 #

如果对插入可靠性有极高要求，可以在拿到SendReceipt中的MessageId之后，调用PeekMessagesAsync接口定向校验对应ID的消息是否真实存在。相比全队列计数的方案，这种定向校验的准确性更高，且仅需1次额外请求，不会被其他队列操作干扰。

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