您应该使用SDK的重试逻辑。正如您在文档中发现的，它处理瞬时错误;换句话说，这些错误可能很快就会自行解决。429就是一个教科书的例子，因为你的输入是完全有效的，但是后端无法处理它此时。
虽然您可以实现自己的逻辑，但有几个理由可以让SDK来处理。而在实践中，人们更了解什么是暂时性错误，什么不是。SDK知道x-ms-retry-after-ms报头，该报头指定重试应等待最短时间，从而避免不必要的流量。如果有任何功能影响重试逻辑，SDK维护得很好。
在创建CosmosClient时，您还可以自定义选项以满足重试逻辑的需要：

var options = new CosmosClientOptions()
{
    MaxRetryAttemptsOnRateLimitedRequests = 100,
    MaxRetryWaitTimeOnRateLimitedRequests = TimeSpan.FromMinutes(5),
};

字符串

您链接的文章有一个重试部分，它会导致：https://learn.microsoft.com/en-us/azure/cosmos-db/conceptual-resilient-sdk-applications#should-my-application-retry-on-errors
这涵盖了每个StatusCode的重试次数，包括429：
Azure Cosmos DB SDK默认情况下将在出现HTTP 429错误时按照客户端配置进行重试，并遵循服务的响应x-ms-retry-after-ms标头，方法是等待指定的时间并在之后重试。
当超过SDK重试次数时，会将错误传回至应用程序。理想情况下，检查响应中的x-ms-retry-after-ms头可以用作一个提示，以决定在重试请求之前等待多长时间。另一种替代方案是指数回退算法，或者将客户端配置为延长HTTP 429上的重试时间。
无论是读还是写，429都将重试到您可以配置的特定点（或者您甚至可以构建自己的重试行为）。
https://learn.microsoft.com/azure/cosmos-db/nosql/best-practice-dotnet上的措辞有点模糊，需要改进，但当它提到 transient 时，它的意思是提到超时-> https://learn.microsoft.com/azure/cosmos-db/nosql/conceptual-resilient-sdk-applications#timeouts-and-connectivity-related-failures-http-408503