异步

背景 spawn 后丢掉 handle，会让调用方失去等待、错误检查和取消入口。后台任务应该有生命周期所有者，而不是依靠进程退出兜底。 核心判断 单任务保存 JoinHandle，多任务使用 JoinSet 集中回收。 区分业务 Result 与 JoinError 中的 panic、取消。 优先协作停止，必要时 abort 后继续 await 回收结果。 最小示例 下面保留核心逻辑；业务类型、调用入口和环境配置按项目补齐。 let handle = tokio::spawn(async move { worker.run(shutdown).await }); match handle.await { Ok(Ok(())) => tracing::info!("worker stopped"), Ok(Err(err)) => tracing::error!(error = %err, "worker failed"), Err(err) => tracing::error!(error = %err, "worker join failed"), } 边界与误区 丢弃 JoinHandle 会分离任务，并不等于停止任务。worker 和 shutdown 是业务对象，示例只展示持有 handle 和等待的边界。 验证方式 让任务正常返回、失败、panic 和被取消各一次，确认监督者都有处理路径；服务停止时检查没有孤立后台任务继续访问资源。 小结 保存 JoinHandle，集中处理任务完成、错误、panic 和取消，不让后台任务失去所有者。

常见症状 CPU 利用率不低，但吞吐上不去。 延迟长尾集中在少数请求。 日志显示 reactor 活跃，业务任务却排队。 调优抓手 阻塞任务下沉到 spawn_blocking 专用池。 控制单任务计算粒度，避免长时间不让出执行权。 关键路径减少无效唤醒与跨线程迁移。 观测建议 任务排队时长分位数。 阻塞线程池饱和度。 每 worker 的 poll 次数与负载偏斜。 小结 Tokio 调优核心是“让调度器专注调度”。把阻塞工作隔离出去，异步优势才能稳定释放。

背景 这类问题在真实项目里很常见：高并发、复杂依赖、发布频繁、团队协作面广。只有把边界条件提前定义清楚，系统才会在压力下保持稳定。 实践要点 先定义目标：可用性、延迟、成本哪个优先。 把关键路径显式化：超时、重试、降级、回滚。 把策略写进代码和流程，而不是只停留在文档。 代码片段 let result = tokio::time::timeout( std::time::Duration::from_millis(200), do_work(), ).await; 总结 工程实践最怕“看起来正确”。把策略做成可观测、可验证、可回滚的闭环，才能在生产环境里真正稳定运行。 稳定性不是某个技巧，而是持续的系统化约束。