Rust 上生产环境：那些没人提前告诉你的事

你决定用 Rust 写下一个 Web 应用了？恭喜，你踏上了一条能让你编程水平突飞猛进、同时也能把你的耐心磨到极限的路。

不是说我讨厌 Rust。恰恰相反，我用 Rust 跑生产环境已经两年多了，性能提升是实打实的。但说实话，Rust 的 Web 开发生态还在成长阶段，有些事情从 Node.js、Python 这些成熟生态转过来的话，真的会措手不及。

今天聊聊那些 hype 背后没人提的真实问题。

async 异步这关，真的不好过

Rust 的 async/await 语法看着挺简洁的，但真想搞懂它底层怎么跑的，得花时间慢慢建立一套思维模型。跟 JavaScript 的事件循环或者 Python 的 asyncio 不一样，Rust 的异步是"显式"的——你得清清楚楚知道运行时会发生什么。

本来就想发个简单的 HTTP 请求，结果一头栽进 async 上下文里的生命周期问题，那叫一个酸爽。编译器的报错确实有用，但对新手来说，有时候报错信息太多了反而脑子转不过来。做好心理准备，头几个星期你会跟借用检查器死磕。

依赖地狱这事儿，Rust 也不省心

生态确实大了不少，但库之间的兼容问题还是烦人。你可能碰上这种情况：某个 crate 好久没更新了，而且跟最新版的 Rust 明显不兼容。Rust 的语义化版本总体做得不错，但一旦出问题，往往是大问题。

Actix-web 和 Axum 这种框架挺稳的，但你会发现，有些号称"久经沙场"的 crate，其实压根没在大规模场景下实战过。文档质量参差不齐，有些关键依赖就一个开发者维护，搞不好人家消失几个月没动静。

编译速度这事儿，能把你磨没脾气

deadline 火烧眉毛的时候，看着编译 release 版本等个五分钟，那感觉懂的都懂。增量编译是改进了不少，但 Rust 依然是业界编译最慢的语言之一。反馈循环拖慢了，CI/CD 流水线跑一次也比预想的久。

这可不只是烦人——直接影响你迭代功能的速度，也影响团队对测试的态度。有些团队干脆把项目拆成更小的 crate 来缓解，但那就引入了另一套复杂度。

人才库还是有点浅

招到有经验的 Rust 开发者，比招 Python 或者 JavaScript 工程师难多了。招聘帖发出去可能引来不少感兴趣的简历，但想组建一支能马上上手的团队，还真得花点时间。这倒不是致命问题，但创业公司想快速跑起来的话，确实得掂量掂量。

好消息是，用 Rust 的开发者普遍比较靠谱、思考问题也比较深入。社区氛围友好，语言本身吸引的都是真心想学习的人。

那到底该不该用 Rust 做 Web 开发？

用啊——但期望值得调低一点。Rust 特别适合性能敏感的服务、系统编程、以及内存安全确实是刚需的场景。如果你要搭一个 API，每秒处理几千请求、延迟还要压到很低，Rust 绝对能打。

但如果你是在原型阶段、正在做 MVP、或者团队需要快速交付，Rust 目前的开销可能不太值得。不过好消息是，工具链和生态每个月都在变好，我预计再过几年这些摩擦点都会慢慢消化的。

我的建议？先从一个小而美的、非关键的服务开始上手。熟悉一下这套玩法，看看团队跟 Rust 的"性格"合不合，再考虑要不要大动干戈搞重写。Rust 不会消失，等生态再成熟一些、对你项目更友好的时候再全面拥抱，完全没问题。

那些没人提的问题确实存在，但都不是过不去的坎。说真的，当你部署一个 Rust 服务，跑得稳稳当当只有 2% CPU，却扛住了真刀真枪的流量，那感觉还是挺爽的。

你们团队 Rust 上生产的体验怎么样？评论区聊聊呗——什么坑踩过、什么好使，都想听听。