Tokio 团队做运行时、做 ORM，今天把这两件事接到一起，做了个全栈框架。7月22日，Topcoat 正式发布，没有 WASM，没有前后端分离，Rust 代码写一遍，服务端渲染和浏览器交互都能跑。思路更像 Phoenix LiveView 和 HTMX，而不是 Leptos 或者 Dioxus。

Tokio 创始人 Carl Lerche 说过，「Rust 要进前三，得有 Rails」。三年后这句话正在变成现实。

**不用 WASM 怎么做响应式？**

Leptos 和 Dioxus 把 Rust 编译成 WebAssembly 跑在浏览器里，性能很强但包体积大，浏览器和服务器之间还要序列化数据，配置起来也麻烦。Topcoat 走了另一条路。

所有 HTML 在服务端渲染，组件可以是 async 的，可以直接查数据库、验证用户权限，不需要单独的 API 层。想加点交互，就用 `$(…)` 宏把一小段 Rust 表达式交叉编译成 JavaScript，直接跑在浏览器里，不需要 WASM，不需要构建步骤。官方给的例子是一个折叠按钮，用 signal 声明状态，`@click` 绑定 Rust 闭包，`:hidden` 属性自动追踪状态变化——整个切换逻辑在浏览器里跑，一次服务端请求都不用。

也可以让某个区域在服务端重新渲染，然后只替换页面里变化的那一小块。比如搜索框输入的时候，结果列表在服务端查询数据库，再返回给浏览器，思路和 HTMX 的 hypermedia exchange 如出一辙。

**为什么是现在？**

Carl Lerche 在官方博客里解释得很直接：AI 编程工具把语言门槛抹平了，会 Rust 的和不会 Rust 的，在 AI 辅助下写 Rust 的差距已经没那么大了。已经有团队在没有 Rust 经验的工程师手里用 AI 工具跑通 Rust 项目。这意味着用 Rust 写全栈应用的心智负担在下降，但缺少一个像 Rails 那样「电池齐全」的框架——Topcoat 补的就是这个位置。

Tokio 团队已经做好了 Toasty ORM（2026年4月 GA），这次 Topcoat 是第二步。后续 Roadmap 里有 Auth、WebSocket、Streaming SSR。

**实际用起来什么样？**

最小 app 长这样：

“`rust
#[tokio::main]]
async fn main() {
topcoat::start(Router::builder().discover().build()).await.unwrap();
}

#[page(“/”)]
async fn home() -> Result {
view! {

hello(name: “World”)

}
}

#[component]
async fn hello(name: &str) -> Result {
view! {

“Hello, ” (name) “!”

}
}
“`

路由用模块路径自动推断，`#[page(“/”)]` 声明页面，`#[component]` 声明组件，`view!` 写模板，内置 Tailwind 集成和静态资源管道。

**现在能用了吗？**

不能算生产就绪。官方自己说了：breaking changes 预期会发生，HTMX/Alpine.js 集成还是可选的过渡方案。Tokio 团队背书的项目通常生命周期不会太短，但成熟度确实还需要时间。

**和其他方案比怎么样？**

直接竞品是 Leptos 和 Dioxus，这俩走的都是 WASM 路线，包体积和序列化开销是客观存在的。Topcoat 的优势在于不需要 WASM，门槛更低，适合不需要极致交互的应用。如果团队已经用 Axum，Topcoat 是顺滑升级路径。

**三个下一步**

第一，用官方 CLI 起一个小项目跑一遍，感受 `#[page]` / `#[component]` / `view!` 的开发体验。第二，读一下 Toasty ORM 的文档，这会是 Topcoat 栈的数据层基础。第三，关注 Roadmap，Auth 和 WebSocket 落地之后生产可用性会大幅提升。

Topcoat 的出现补完了 Rust 全栈的最后一块拼图。用 Carl Lerche 的话说：「Rust 要进前三，得有 Rails。」现在 Rails 有了，接下来看社区买不买单。