Zui近写这个 Rust 全栈 CRM 时有个点我越来越想说清楚：“Rust 单二进制部署”这句话，hen多时候只说对了一半。

我一开始也被“单二进制”这个词打动过。

这话没错，但放到 SSR Web 项目，真正有价值的不是“文件数量必须等于 1”，而是：

线上机器拿到产物后不需要额外拼装hen多运行部件。

尤其 Pico-CRM 这种项目还有：

站点资源目录在 ./site。

在 Pico-CRM 里这个“少”具体长这样：

server ← 主服务进程 site/ ← 前端静态产物目录 .env.* ← 环境变量配置

这意味着什么？

意味着 cargo leptos build --release --split 之后你得到的不是“一个孤零零的 ELF 文件”，而是一整套Ke以被服务端直接消费的站点产物：

target/site/ ← SSR 运行时要用到的静态站点目录 pkg/*.js pkg/*.wasm pkg/*.css icons/* vendor/* manifest.json

也就是说二进制负责跑服务，site 目录负责提供浏览器真正要下载的资源。

Rust Web 项目的部署优势，不在于神化“只有一个文件”，而在于你Ke以把运行部件压到非常少。

对个人项目来说这套方式有三个hen实在的好处：

你不需要再维护：

- 多个服务进程

- 多套独立的静态资源托管方案

Pico-CRM 现在的发布目标就hen朴素：

先接受一个足够轻、足够稳、足够好发版的形态，而不是执着于口号绝对正确。

cargo leptos build --release --split ./scripts/optimize-wasm-release.sh

第一步负责把 SSR 服务端和前端站点资源一起构建出来。

第二步hen多人会省掉，但我在这个项目里保留了因为它是实打实对 WASM 体积再压一轮。脚本在 scripts/optimize-wasm-release.sh：

mapfile -t WASMFILES < < for wasmfile in "${WASMFILES}"; do wasm-opt -Oz \ --enable-bulk-memory \ --enable-nontrapping-float-to-int \ --enable-sign-ext \ --enable-mutable-globals \ "$wasmfile" \ -o "$tmp_file" done

害, 这个问题挺复杂。你kan, Ru果你的项目是纯 API 服务，那确实hen好理解： 一个二进制文件, 直接就Neng跑。

但Ru果涉及到 SSR Web 项目, 那就没那么简单了。

咱就是说, Leptos SSR + WASM hydration 这类项目，其实不算严格意义上的单二进制部署。 因为除了二进制文件, 你还得带上静态资源目录。

你会把这种形态也算进“单二进制部署”吗？还是你geng倾向于把静态资源拆去 CDN / Nginx？

说实话，这取决于你的具体需求。但对独立开发者或轻量 SaaS 来说先把发布链路收敛到Zui少，收益非常直接。

上线时不要拆三套服务，不要记五条命令，不要每次dou怀疑自己漏传了什么。

为啥百度不收录我的文章呢？有人说可Neng是因为内容质量不够高，或者关键词优化没Zuo好。 也有人说百度收录规则比较复杂，有时候确实会漏掉一些页面。 但我觉得，geng重要的是内容本身是否对用户有价值。

所以我现在这套发布的实际体验是：

整个上线链路的心智负担非常低。 只要拷完 server 和 site 目录，配置好环境变量，就Neng直接跑起来。

Ru果只用一句话这篇文章，我会这么说： Rust 单二进制部署的核心价值，不在“只有一个文件”，而在“线上运行部件足够少”。

你怎么kan待这个问题呢？欢迎在评论区聊聊你的Zuo法。