Tokio 团队出品 Toasty：重新定义 Rust 异步 ORM 的工程哲学

写在前面

2026年4月，Rust 生态迎来了一颗重磅炸弹——Toasty，来自 Tokio 团队的全新异步 ORM 框架。

Tokio 团队是什么分量？他们在 Rust 生态中的地位，堪比 Spring 之于 Java、Koa/Echo 之于 Node.js。Tokio（异步运行时）、tracing（日志库）、prost（Protobuf 库）、axum（Web 框架）、loom（并发测试库）——这些 Rust 后端开发的必备基础设施，几乎全是这个团队的作品。

而现在，他们进军 ORM 了。

这意味着什么？意味着 Toasty 不是一个人晚上写着玩的玩具项目，不是某个创业公司用来吸引眼球的 Demo，而是 Rust 生态核心团队在经过深思熟虑后，对"Rust 异步数据访问"这一领域给出的官方答案。

本文将带你深入理解 Toasty 的设计哲学、架构内核、工程实践与性能表现，以及它与现有 Rust ORM 生态（如 Diesel、SeaORM、SQLx）之间的核心差异。

一、为什么 Rust 生态需要一个新的 ORM？

1.1 现有方案的困境

在 Toasty 出现之前，Rust 生态的 ORM 格局大致可以分为三类：

第一类：编译期 SQL 生成（Diesel）

Diesel 是 Rust 生态中最老牌的 ORM，设计理念与 Rails 的 ActiveRecord 类似——在编译期通过 DSL 将 Rust 代码翻译为 SQL。Diesel 的优势是类型安全、性能卓越（生成的 SQL 经过优化），但劣势也同样明显：

• 配置复杂，迁移成本高
• 编译时间长，每次修改模型都需要重新编译
• 对于 NoSQL 和特殊数据库支持有限
• async/await 生态成熟后，其同步优先的设计显得格格不入

// Diesel 风格的查询
use diesel::prelude::*;

let users = users::table
    .filter(users::name.eq("Alice"))
    .load::<User>(&conn)?;

第二类：运行时查询构建器（SeaORM）

SeaORM 采用了更灵活的运行时策略，支持异步，提供了较好的开发者体验。但它本质上仍然是一个 SQL 生成工具，模型层与数据库 schema 耦合较重，学习曲线陡峭。

// SeaORM 风格的查询
use sea_orm::*;

let users = User::find()
    .filter(UserColumn::Name.eq("Alice"))
    .all(&db)
    .await?;

第三类：直接 SQL 执行器（SQLx）

SQLx 走的是最极简路线——不做任何抽象，直接将 SQL 字符串发给数据库，通过编译期宏验证 SQL 正确性。它性能极佳，但完全不提供模型抽象，开发者需要自己处理序列化/反序列化。

// SQLx 风格的查询
let user = sqlx::query_as::<_, User>("SELECT * FROM users WHERE name = $1")
    .bind("Alice")
    .fetch_one(&pool)
    .await?;

这三类方案各有取舍，但它们都有一个共同的根本问题：没有一款 ORM 将"应用层 schema 与数据库 schema 完全解耦"作为核心设计目标。

1.2 Toasty 的破局思路

Tokio 团队在设计 Toasty 时，提出了一个核心理念：Toasty 不是 SQL 生成工具，而是"应用级查询引擎"（Application Query Engine）。

这个定位非常关键。传统 ORM 将自己视为"数据库的替身"，试图让开发者用面向对象的方式操作数据库。而 Toasty 的思路是：应用层应该有自己的领域模型（domain model），数据库只是一个持久化后端，两者是解耦的。

这意味着：

• 你的 Rust 代码中的 struct User 不需要与数据库的 users 表一一对应
• 可以一个 Rust 类型映射到多个数据库表
• 可以跨数据库（SQLite + PostgreSQL + DynamoDB）使用同一套查询 API
• 可以针对不同数据库的特性做查询优化

这个设计哲学，与 Entity-Component 分离 的思想一脉相承，也与现代微服务架构中"数据库不是你的数据模型"的理念高度一致。

二、Toasty 架构深度解析

2.1 整体架构

Toasty 的架构可以分为三层：

┌─────────────────────────────────────────────────┐
│              Application Layer                   │
│   (Your Rust Code - Domain Models, Business Logic)│
├─────────────────────────────────────────────────┤
│              Toasty Query Engine                  │
│  (Schema Abstraction, Query Translation, Optimizer)│
├──────────────┬──────────────┬───────────────────┤
│  SQLite      │  PostgreSQL  │     DynamoDB      │
│  Driver      │  Driver      │     Driver         │
├──────────────┴──────────────┴───────────────────┤
│              Database Layer                       │
│        (SQLite, PostgreSQL, DynamoDB)             │
└─────────────────────────────────────────────────┘

关键理解：Toasty 的查询引擎层负责将统一的高层查询语法，翻译为特定数据库的最优查询。它不追求消除数据库特性，而是通过 feature gate 引入不同数据库的高级特性。

2.2 模型抽象层

Toasty 的模型定义通过 derive 宏完成，这是 Rust 生态最标准的方式：

use toasty::Model;

#[derive(Debug, Model)]
struct User {
    // 主键，自动递增
    #[key]
    #[auto]
    id: u64,
    
    // 普通字段
    name: String,
    
    // 唯一约束
    #[unique]
    email: String,
    
    // 可选字段
    age: Option<i32>,
    
    // 时间戳，自动管理
    created_at: DateTime,
}

对比其他 ORM，Toasty 的模型定义有几点独特之处：

1. #[key] 与 #[auto] 分离

在很多 ORM 中，主键和自增策略混在一起。Toasty 将其分离，允许你：

• 使用 #[auto] 表示数据库自动生成（如 AUTO_INCREMENT）
• 使用 #[default] 或显式赋值来管理复合主键

2. #[unique] 字段级别的唯一约束

与 SeaORM 的 DeriveEntityModel 或 Diesel 的 table! 宏相比，Toasty 的字段级约束注解更加直观。

3. 没有外键关联（Relationship）的显式声明

这是 Toasty 的一个重要设计决策——它有意不提供传统 ORM 中的 has_many、belongs_to 宏。因为 Toasty 认为这些隐式关联会增加耦合，降低查询的灵活性。取而代之的是，你可以通过显式的 JOIN 查询或独立的查询来表达关联关系。

2.3 查询引擎层

Toasty 的查询引擎是其最核心也是最复杂的部分。它提供了一套统一的查询 API，可以翻译为不同数据库的原生查询。

字段查询语法

// 构建字段访问器
let fields = User::fields();

// 等值查询
User::filter(fields.name().eq("Alice"))

// 范围查询
User::filter(fields.age().gt(25).and(fields.age().lt(50)))

// 模糊查询（针对支持 LIKE 的数据库）
User::filter(fields.email().like("%@example.com"))

// 复合条件
User::filter(
    fields.name().eq("Alice")
    .and(fields.age().gte(18))
    .or(fields.name().eq("Bob"))
)

这套字段 API 看起来与其他 ORM 类似，但背后的实现有一个本质区别：字段访问器（Field Accessor）是数据库无关的抽象层。当你调用 fields.name().eq("Alice") 时，Toasty 不会立即生成 SQL，而是构建一棵查询语法树（Query AST），然后在执行阶段根据目标数据库类型选择最优的 SQL 生成策略。

// 字段访问器的内部结构（简化版）
pub struct FieldAccessor {
    table: TableRef,
    column: ColumnRef,
    db_type: DbType,
}

impl FieldAccessor {
    pub fn eq<T: Encode>(&self, value: T) -> Condition {
        Condition::Binary {
            left: self.clone(),
            op: Operator::Eq,
            right: Expr::Constant(value.encode()),
        }
    }
}

翻译策略

以一个简单的等值查询为例：

User::filter(User::fields().name().eq("Alice"))

针对 SQLite：

SELECT * FROM users WHERE name = 'Alice'

针对 PostgreSQL：

SELECT * FROM users WHERE name = $1  -- 使用参数化查询

针对 DynamoDB：

{
  "FilterExpression": "#name = :name",
  "ExpressionAttributeNames": { "#name": "name" },
  "ExpressionAttributeValues": { ":name": { "S": "Alice" } }
}

同一套 Rust 代码，在不同数据库上生成了完全不同的查询策略。这正是 Toasty "应用级查询引擎"定位的具体体现。

2.4 驱动层

Toasty 的驱动层设计遵循插件化原则，每种数据库都有一个独立的驱动实现：

// 在 Cargo.toml 中按需启用
[dependencies]
toasty = { version = "0.3", features = ["sqlite"] }      // 仅 SQLite
toasty = { version = "0.3", features = ["postgresql"] }  // 仅 PostgreSQL
toasty = { version = "0.3", features = ["mysql"] }       // 仅 MySQL
toasty = { version = "0.3", features = ["dynamodb"] }    // 仅 DynamoDB

// 全量支持
toasty = { version = "0.3", features = ["full-db"] }

驱动层负责：

• 数据库连接的建立与池化（connection pooling）
• SQL 语句的发送与结果接收
• 类型映射（Rust 类型 ↔ 数据库类型）
• 错误处理与重试策略

Tokio 团队在驱动层的实现中，大量复用了他们多年打磨的连接池技术（基于 tokio-postgres、tokio-rusqlite 等底层库），确保了最高的运行时性能。

三、工程实践：从入门到精通

3.1 项目初始化

cargo new myapp && cd myapp

# Cargo.toml
[package]
name = "myapp"
version = "0.1.0"
edition = "2024"

[dependencies]
toasty = { version = "0.3", features = ["sqlite", "postgresql"] }
tokio = { version = "1", features = ["full"] }
serde = { version = "1", features = ["derive"] }

3.2 完整的 CRUD 操作

use toasty::{Model, Db, Result};
use toasty::operators::*;

#[derive(Debug, Model)]
struct Article {
    #[key]
    #[auto]
    id: u64,
    
    title: String,
    
    content: String,
    
    author_id: u64,
    
    #[unique]
    slug: String,
    
    published: bool,
    
    views: i32,
    
    created_at: DateTime,
}

#[tokio::main]
async fn main() -> Result<()> {
    // 构建数据库连接
    let mut db = Db::builder()
        .models(toasty::models!(crate::*))
        .connect("sqlite:./myapp.db")
        .await?;
    
    // 创建表
    db.push_schema().await?;
    
    // ═══════════════════════════════════════
    // CREATE - 创建记录
    // ═══════════════════════════════════════
    
    // 方式一：create! 宏（推荐）
    let article = toasty::create!(Article {
        title: "深入理解 Rust 异步编程",
        content: "本文将带你深入理解 Rust 的 async/await...",
        author_id: 1,
        slug: "understanding-rust-async",
        published: true,
        views: 0,
    })
    .exec(&mut db)
    .await?;
    println!("创建文章: {} (ID: {})", article.title, article.id);
    
    // 方式二：链式 Builder 模式
    let draft = Article::create()
        .title("Rust 异步运行时深度解析")
        .content("Tokio 是 Rust 生态中最成熟的异步运行时...")
        .author_id(1)
        .slug("rust-async-runtime-deep-dive")
        .published(false)
        .views(0)
        .exec(&mut db)
        .await?;
    
    // 方式三：批量创建
    let articles = toasty::create!(Article::[
        {
            title: "Go 1.24 Swiss Table 解析",
            content: "Go 1.24 引入了 Swiss Table...",
            author_id: 1,
            slug: "go-1-24-swiss-table",
            published: true,
            views: 150,
        },
        {
            title: "前端框架 2026 趋势分析",
            content: "2026 年，前端框架格局发生了显著变化...",
            author_id: 2,
            slug: "frontend-framework-2026",
            published: true,
            views: 320,
        },
    ])
    .exec(&mut db)
    .await?;
    println!("批量创建了 {} 篇文章", articles.len());
    
    // ═══════════════════════════════════════
    // READ - 查询记录
    // ═══════════════════════════════════════
    
    // 通过主键查询
    let found = Article::get_by_id(&mut db, &article.id).await?;
    println!("查询到文章: {}", found.title);
    
    // 获取所有记录
    let all = Article::all().exec(&mut db).await?;
    println!("总文章数: {}", all.len());
    
    // 条件查询 - 精确匹配
    let published = Article::filter(
        Article::fields().published().eq(true)
    )
    .exec(&mut db)
    .await?;
    println!("已发布文章数: {}", published.len());
    
    // 条件查询 - 范围查询
    let popular = Article::filter(
        Article::fields().views().gt(100)
    )
    .exec(&mut db)
    .await?;
    println!("浏览量 > 100 的文章数: {}", popular.len());
    
    // 条件查询 - 多条件组合
    let target = Article::filter(
        Article::fields().published().eq(true)
        .and(Article::fields().author_id().eq(1))
        .and(
            Article::fields().title().like("%Rust%")
            .or(Article::fields().title().like("%Go%"))
        )
    )
    .exec(&mut db)
    .await?;
    println!("符合条件的文章数: {}", target.len());
    
    // 排序与分页
    let sorted = Article::all()
        .order_by(Article::fields().views().desc())
        .limit(5)
        .exec(&mut db)
        .await?;
    println!("浏览量前5的文章:");
    for a in &sorted {
        println!("  - {} (浏览: {})", a.title, a.views);
    }
    
    // ═══════════════════════════════════════
    // UPDATE - 更新记录
    // ═══════════════════════════════════════
    
    // 方式一：通过实体更新
    let mut to_update = Article::get_by_id(&mut db, &article.id).await?;
    to_update.title = "深入理解 Rust 异步编程（修订版）".to_string();
    to_update.views += 1;
    to_update.update()
        .exec(&mut db)
        .await?;
    println!("更新了文章标题");
    
    // 方式二：通过查询条件批量更新
    let updated_count = Article::filter(
        Article::fields().author_id().eq(1)
    )
    .update()
    .views(Article::fields().views() + 1)  // 原子递增
    .exec(&mut db)
    .await?;
    println!("更新了 {} 篇文章的浏览量", updated_count);
    
    // ═══════════════════════════════════════
    // DELETE - 删除记录
    // ═══════════════════════════════════════
    
    // 方式一：通过实体删除
    let to_delete = Article::get_by_id(&mut db, &draft.id).await?;
    to_delete.delete().exec(&mut db).await?;
    println!("删除了草稿文章");
    
    // 方式二：通过条件批量删除
    let deleted = Article::filter(
        Article::fields().published().eq(false)
        .and(Article::fields().views().eq(0))
    )
    .delete()
    .exec(&mut db)
    .await?;
    println!("删除了 {} 篇无用草稿", deleted);
    
    // ═══════════════════════════════════════
    // TRANSACTION - 事务操作
    // ═══════════════════════════════════════
    
    let mut tx = db.transaction().await?;
    
    toasty::create!(Article {
        title: "事务测试文章",
        content: "这是一篇用于测试事务的文章",
        author_id: 1,
        slug: "transaction-test",
        published: true,
        views: 0,
    })
    .exec(&mut tx)
    .await?;
    
    // 模拟更新（故意先不提交）
    let created = Article::filter(
        Article::fields().slug().eq("transaction-test")
    )
    .exec(&mut tx)
    .await?;
    
    if !created.is_empty() {
        let mut article = created.into_iter().next().unwrap();
        article.views = 999;
        article.update().exec(&mut tx).await?;
    }
    
    // 提交事务
    tx.commit().await?;
    println!("事务已提交");
    
    // 回滚示例（注释掉 commit 则自动回滚）
    // tx.rollback().await?;
    
    // ═══════════════════════════════════════
    // 高级查询：聚合与统计
    // ═══════════════════════════════════════
    
    // 统计查询
    let total = Article::count().exec(&mut db).await?;
    println!("文章总数: {}", total);
    
    let published_count = Article::filter(
        Article::fields().published().eq(true)
    )
    .count()
    .exec(&mut db)
    .await?;
    println!("已发布文章数: {}", published_count);
    
    // 存在性检查
    let exists = Article::filter(
        Article::fields().slug().eq("understanding-rust-async")
    )
    .exists()
    .exec(&mut db)
    .await?;
    println!("文章是否存在: {}", exists);
    
    Ok(())
}

3.3 与 Axum Web 框架集成

这是 Toasty 最典型的应用场景——作为 Tokio 团队自家 Web 框架 Axum 的数据访问层：

use axum::{
    extract::{Path, State},
    http::StatusCode,
    response::Json,
    routing::{get, post},
    Router,
};
use toasty::{Model, Db};
use serde::{Deserialize, Serialize};

#[derive(Debug, Clone)]
struct AppState {
    db: Db,
}

#[derive(Debug, Serialize, Deserialize)]
struct CreateArticleRequest {
    title: String,
    content: String,
    author_id: u64,
    slug: String,
}

// RESTful 路由设置
fn app_router(db: Db) -> Router {
    Router::new()
        .route("/articles", get(list_articles))
        .route("/articles/:id", get(get_article))
        .route("/articles", post(create_article))
        .route("/articles/:id", axum::routing::delete(delete_article))
        .with_state(AppState { db })
}

async fn list_articles(
    State(state): State<AppState>,
) -> Result<Json<Vec<Article>>, StatusCode> {
    let articles = Article::all()
        .order_by(Article::fields().created_at().desc())
        .exec(&mut state.db.clone())
        .await
        .map_err(|_| StatusCode::INTERNAL_SERVER_ERROR)?;
    Ok(Json(articles))
}

async fn get_article(
    State(state): State<AppState>,
    Path(id): Path<u64>,
) -> Result<Json<Article>, StatusCode> {
    Article::get_by_id(&mut state.db.clone(), &id)
        .await
        .map(Json)
        .map_err(|_| StatusCode::NOT_FOUND)
}

async fn create_article(
    State(state): State<AppState>,
    Json(req): Json<CreateArticleRequest>,
) -> Result<(StatusCode, Json<Article>), StatusCode> {
    let article = Article::create()
        .title(req.title)
        .content(req.content)
        .author_id(req.author_id)
        .slug(req.slug)
        .published(false)
        .views(0)
        .exec(&mut state.db.clone())
        .await
        .map_err(|_| StatusCode::INTERNAL_SERVER_ERROR)?;
    Ok((StatusCode::CREATED, Json(article)))
}

async fn delete_article(
    State(state): State<AppState>,
    Path(id): Path<u64>,
) -> Result<StatusCode, StatusCode> {
    let article = Article::get_by_id(&mut state.db.clone(), &id)
        .await
        .map_err(|_| StatusCode::NOT_FOUND)?;
    article.delete()
        .exec(&mut state.db.clone())
        .await
        .map_err(|_| StatusCode::INTERNAL_SERVER_ERROR)?;
    Ok(StatusCode::NO_CONTENT)
}

3.4 迁移管理

Toasty 提供了 Schema 管理 API，用于数据库结构的版本化演进：

#[tokio::main]
async fn main() -> Result<()> {
    let mut db = Db::builder()
        .models(toasty::models!(crate::*))
        .connect("sqlite:./myapp.db")
        .await?;
    
    // 自动创建或更新表结构
    // Toasty 会对比当前数据库 schema 与代码中定义的 schema
    // 自动生成 ALTER TABLE 语句
    db.push_schema().await?;
    
    println!("Schema 迁移完成");
    
    // 如果需要重置 schema（危险！会丢失数据）
    // db.reset_schema().await?;
    
    Ok(())
}

⚠️ 注意：push_schema() 只会添加缺失的列和表，不会删除已有数据。对于更复杂的迁移场景（如重命名列、修改约束），建议配合 SQL 迁移脚本使用。

四、性能基准测试

作为 Tokio 团队的作品，Toasty 的性能表现自然是我们最关心的维度。以下是与主流 Rust ORM 的性能对比（基于公开基准测试数据，测试环境：Apple M3 Pro, 18GB RAM）：

4.1 基准测试设置

// 测试配置
const ITERATIONS: usize = 10_000;
const BATCH_SIZE: usize = 100;

// 测试设备：Apple M3 Pro
// 数据库：SQLite（内存模式）
// 操作系统：macOS 15.4

4.2 单条插入性能

Toasty 的单条插入性能非常优秀，这主要得益于：

• 轻量级的驱动层实现（基于 rusqlite 的同步模式 + Tokio 异步包装）
• 宏生成代码的零运行时开销
• 批处理优化（create! 宏在底层会合并多条 INSERT）

4.3 批量插入性能（100条/批次）

批量插入中 Toasty 的优势更加明显，因为其底层驱动对批处理有特殊优化。

4.4 查询性能

纯查询性能上，直接裸写 SQL 的 SQLx 仍然最快，但 Toasty 与之的差距已经非常小（10-30%），考虑到 Toasty 带来的开发效率提升，这个差距完全可以接受。

五、Toasty vs 其他 ORM：深度对比

5.1 设计哲学对比

5.2 适用场景分析

选择 Toasty 的理由：

1. 你正在使用 Tokio/Axum 构建高性能 Web 服务
2. 你的应用层需要同时访问多个不同类型的数据库
3. 你希望模型层与数据库 schema 保持松耦合
4. 你追求开发效率与性能的平衡

仍然选择 Diesel 的理由：

1. 你的项目需要最高级别的类型安全
2. 你在使用同步场景（无 async 需求）
3. 你需要复杂的数据库迁移管理
4. 你的团队对稳定性要求极高，不接受预览版

仍然选择 SQLx 的理由：

1. 你的查询逻辑非常复杂，需要精细的 SQL 控制
2. 你的团队对 ORM 有不信任感，偏好直接写 SQL
3. 你在使用非常规数据库特性

六、当前局限性与未来展望

6.1 当前局限性

Toasty 目前仍处于预览版（v0.3），存在以下已知限制：

1. API 尚未稳定

Tokio 团队明确表示，未来版本可能存在破坏性变更。在 API 稳定之前，不建议在生产环境中使用。

2. 迁移工具不够成熟

当前只提供了基础的 push_schema() 功能，缺少：

• 迁移版本管理（类似于 Rails 的 db/migrate/）
• 回滚支持
• 数据迁移脚本生成

3. 生态还不够丰富

相比 Diesel（多年积累）和 SeaORM（有活跃社区），Toasty：

• 缺乏官方 CLI 工具
• 缺少集成测试框架
• 没有成熟的可视化管理工具

4. 关联查询（JOIN）的支持

目前 Toasty 对复杂 JOIN 查询的支持较为基础。对于需要大量联表操作的业务场景，可能需要绕道。

6.2 未来展望

根据 Tokio 团队在 GitHub 和博客中透露的路线图，Toasty 的未来发展将聚焦：

v0.4 - v0.5（2026 Q2-Q3）：

• API 稳定化，发布 1.0 预览
• 完整的迁移管理系统
• 官方 CLI 工具
• 改进的 JOIN 支持

v1.0（2026 年底）：

• 生产级别稳定性保证
• 完整的迁移工具链
• 与 Axum 的深度集成示例
• 云数据库支持（PlanetScale、Turso 等）

长期规划：

• GraphQL 集成层
• 实时数据订阅（基于数据库变更流）
• AI 辅助查询优化

七、实战建议：如何在项目中引入 Toasty

7.1 引入策略

阶段一：尝鲜与学习（当前）

在个人项目或非关键模块中引入 Toasty，熟悉其 API 和设计理念：

[dependencies]
toasty = { version = "0.3", features = ["sqlite"] }

阶段二：评估与对比

将 Toasty 与你当前使用的 ORM 在同一模块中做对比测试，重点评估：

• API 舒适度（开发体验）
• 性能差距（在你的业务场景下）
• 迁移成本

阶段三：渐进式迁移

如果评估结果积极，可以逐步将新模块迁移到 Toasty，而不是全面替换：

• 新功能用 Toasty
• 存量功能保持不动
• 待 1.0 发布后再做大规模迁移

7.2 注意事项

1. 始终保留数据库 Schema 的备份：Toasty 的 push_schema() 行为在某些边界情况下可能与你预期的不一致
2. 监控 API 变更：Tokio 团队每次版本发布前都会在 GitHub 上发布变更预告，请及时关注
3. 不要在核心数据访问路径上完全依赖 Toasty：在 1.0 稳定版发布前，建议保留 SQLx 作为降级方案

总结

Toasty 是 Rust 异步 ORM 生态中一股令人兴奋的新力量。它代表了 Tokio 团队对"应用级数据访问"这一命题的深度思考——不追求消除数据库特性，而是通过统一的查询抽象层，让开发者能够以数据库无关的方式构建应用逻辑。

它的优势在于：

• Tokio 团队背书：品质有保障，与 Axum 无缝衔接
• Schema 完全解耦：真正的领域驱动设计友好
• 多数据库原生支持：一个代码库，多种数据库后端
• 优秀的性能表现：与裸 SQL 的性能差距已经很小

它的风险在于：

• 预览版状态：API 存在破坏性变更的可能
• 生态尚不成熟：迁移工具、CLI、生态集成都需要时间打磨

一句话评价：如果你正在使用 Tokio/Axum 构建 Rust Web 服务，Toasty 是目前最值得期待的 ORM 选择，值得保持关注。如果你的项目需要高稳定性保障，建议等到 1.0 正式版发布后再做引入决策。

链接资源：

• GitHub: https://github.com/tokio-rs/toasty
• 官方文档: https://docs.rs/toasty
• Tokio 团队博客: https://tokio.rs/blog

本文首发于程序员茄子（chenxutan.com），如需转载，请注明出处。