async-std 停更的消息传了有一年了。但大部分人没注意到的是：RustSec 在 2025 年 8 月 27 日正式把 async-std 标记为「unmaintained」，编号 RUSTSEC-2025-0052。这不只是个 GitHub README 更新，而是一个有官方背书的安全公告。

什么叫「停止维护」

async-std 还能用。它没有删库，cargo add async-std 依然可以拉下来，代码依然能跑，测试依然能过。它没有 broken，只是没人管了。

区别在哪里？安全漏洞没人修了。

当一个 crate 被 RustSec 标记为 unmaintained，意味着没有人再监控它的 CVE，没有人再发安全补丁。如果明天 async-std 的某个依赖爆出一个漏洞，你的项目就暴露在那儿，而唯一的修复方式是：你来修。

RustSec advisory 本身不会 block 你的 CI build。这意味着很多团队的 production 代码里安静地躺着一个未维护的依赖，直到某天真出了事。

数字说了一个反直觉的故事

crates.io 的下载数据能说明问题：

• Tokio：总下载 9.35 亿，近 30 天 2.16 亿
• async-std：总下载 9127 万，近 30 天 988 万
• smol（async-std 的官方接替者）：总下载 2192 万，近 30 天 422 万

smol 作为 async-std 官方推荐的迁移目标，近 30 天下载量只有 async-std 的 43%。但 async-std 近 30 天还有 988 万次下载——比 smol 还多 2.3 倍。这些流量里有大量是 transitive dependency 链里间接拉进来的，不是直接依赖。

换句话说：还有很多生产项目在用 async-std，而且自己可能都不知道。

怎么迁

smol 是官方推荐的接替者，出自同一团队（Stjepan Glavina），API 设计上也最接近。迁移路径最干净：

“`toml

Cargo.toml

• async-std = “1.13”

• smol = “2.0”
  “`

“`rust
// main.rs

• [async_std::main]

• [smol::main]

// task spawning

• async_std::task::spawn(async { … })

• smol::spawn(async { … })
  “`

smol 刻意保持了极简设计，async-std 的一些高级工具（比如文件系统异步 API、进程管理等）smol 并不提供。如果你的项目重度依赖这些，就需要迁移到 Tokio，工作量会更大，但 Tokio 的生态最完整。

真正的坑不是迁移代码

真正的坑是社区心理。Rust 开发者倾向于把「unmaintained」理解为「还能用」，然后继续用。RustSec advisory 默认不 block CI BUILD，所以大家照常跑 ci，照常用。

async-std 有 9100 万次总下载。这不是一个可以用「没人在用」来解释的数字。这意味着有大量 production Rust 代码的依赖树里，安静地躺着一个没人维护的 crate。

如果你现在在项目里用 async-std，cargo tree | grep async-std 查一下；如果 Cargo.lock 里出现了，迁移计划最好在接下来几周内排上日程。

不是没有人想过这些问题。左 pad 撤架那年很多人说「不能重蹈覆辙」。但 crates 不会消失，只会停止更新，而你的 CI 永远会 build 成功。当安全漏洞来了，要么你来修，要么等着 CVE 打脸。

async-std 完成了它的历史使命——证明了 async Rust 不必看起来像另一门语言，只要镜像 std 风格即可。这个目标已经实现了。但 production 选型看的不是谁优雅，而是三年后谁来维护。答案是：Tokio。smol 适合学习 async Rust 内部原理。而 async-std，适合留在 2025 年。