一、缘起：为什么要用 Rust 写前端

一年前我在做这个家政 SaaS 程序的时候。面临一个很现实的问题：我是一个人，要写前端、后端、数据库、部署。当时后端已经用 Rust，前端如果再用 React/Vue。就得维护两套语言、两套类型程序、两套建立工具链。按理说，

正好那段时间刷到了 Leptos。一个 Rust 全栈框架，号称可以 SSR + WASM hydration，一个 main.rs 搞定所有事。抱着"大不了回退到 React"的心态，我开了这个坑。

再看提前声明。这不是框架对比文，也不是"Rust 前端暴打 JS"的引战贴。只是在一个真实项目中用了一年之后客观记下来的真实体验。如果你也在考虑用 Rust 写全栈，希望这篇能帮你少走点弯路。

二、初体验：从 cargo-leptos build，到第一页 SSR 渲染出来

再看项目结构，三个 crate，一个思路

Pico-CRM 的代码组织是这样的：

pico-crm/
app/ # 共享代码：components、pages、server functions
frontend/ # WASM 入口：cdylib。只做 hydrate
server/ # SSR 入口：Axum 二进制，处理 HTTP + SSR 渲染
backend/ # 纯业务逻辑：DDD、CQRS、SeaORM

主要是 app crate。它用两个 feature flag 区分编译目标：

# app/Cargo.toml
default =
hydrate =
ssr =

同一个 app crate，在 server 里编译时带 ssr feature——包含后端逻辑、leptos_axumaxumtokio 等完整后端依赖；在 frontend 里编译时带 hydrate feature——只包含前端渲染逻辑，所有后端依赖全部裁剪掉。同一个 函数在 SSR 阶段直接调用本体在 WASM 阶段自动生成 HTTP fetch 调用。第一印象这套设计挺聪明的。 不需要手动定义 API 境约你在 Rust 写函数 Leptos 帮你搞定前后序列化通信。

在中整个启动链路是这样：

// src/main.rs

async fn main { let env = env::var.unwraporelse);let envfile = format! ，dotenvy::fromfilename .unwraporelse);怎么说呢，let db = Database::new.await;Migrator::up,None) .await .unwraporelse);bootstrapcqrs) .await .unwraporelse);let conf = getconfiguration .unwraporelse);let routes = generateroutelist;let dbclone = db.clone;let app = Router::new .leptosrouteswithcontext( &leptosoptions。routes,move || { providecontext);// Database 注入 Leptos Context },{ let leptosoptions = leptosoptions.clone;move || shell) // SSR Shell },) .layer) .fallback) .with_state;let listener = tokio::net::TcpListener::bind.await.unwrap;axum::serve).await.unwrap;}

这里有两点值得展开。话说回来，

第一cargo-leptorouteswithcontext是踩了坑之后版本。模板默认用的是cargo-leptoroutes但那个接口把 context 注入和 shell 渲染塞同闭包导致 Server Function 某些场景下拿不到 context下面节会详细展开这个问题。第二shell函数在lib.rs负责输出 HTML 壳子： // lib.rspub fn shell -> impl IntoView { view!{ <AutoReload options=options.clone/> <HydrationScripts options/> <MetaTags/>

<App/> //页面主体