Rust 异步编程与 Tokio 运行时:先限制次数、预算与取消信号 📅 2026/8/11 19:04:21 Rust 异步编程与 Tokio 运行时先限制次数、预算与取消信号重试看起来很简单失败了就再试一次。但我在练习异步请求时才意识到重试会把一次失败变成更多请求。哪些错误可以重试、等多久、总共尝试几次都要由调用场景决定不能照搬一组固定数字。我会先给请求设总超时只对短暂的网络错误或可确认的临时状态重试。认证失败、参数错误和取消请求通常不应该重试。每次等待加一点随机抖动避免很多任务恰好同一时间再次出发。graph TD Error[请求失败] -- Classify{可重试吗} Classify --|否| Return[返回可诊断错误] Classify --|是| Budget{剩余时间和次数} Budget --|有| Delay[退避加随机抖动] Delay -- Retry[再次请求] Budget --|无| Returnuse std::time::Duration; fn delay_for(attempt: u32, jitter_ms: u64) - Duration { let base 20_u64.saturating_mul(2_u64.saturating_pow(attempt)); Duration::from_millis(base.saturating_add(jitter_ms)) } #[test] fn delay_grows_without_overflowing() { assert!(delay_for(2, 3) delay_for(1, 3)); }这段代码只演示延迟计算不生成伪随机数也不代表适合任何服务。实际实现还要限制最大等待时间、传播取消信号并用测试或压测确认不会在异常时堆积任务。日志里只记录脱敏后的错误类别和尝试次数不记录请求正文或凭据。