这几天知乎的 Rust 区，热闹得像排队交「重写」答卷。有人做了个 OpenIDEA，保留 JetBrains 的使用习惯、底层换成 Rust，打开项目 1 秒，内存只要 169 MB。有人实测 100 万个任务同时等待，Rust 比 Go 少用 86% 内存。还有人把编码助手 Pi 用 Rust 重写成 Rpi，会话启动耗时降了约九成。知乎知乎知乎
每条标题都长得像利好。但就在今日，一篇翻译自工程师 Sean Goedecke 随笔的文章当场泼冷水：软件慢，烂的是设计，不是编程语言，别指望用 AI 重写成 Rust 救命。知乎
数据是真的，假的在哪儿？
先把话说清楚：这些实验大体像样。OpenIDEA 的作者自己标了方法——测试项目 freqtrade（Python，约 770 个文件），热缓存，各跑 5 次取中位数；还主动交代 IDEA 对 Python 的分析深度远超自家项目，两边「就绪」干的活并不等量，v0.1.x 也仍是早期。百万任务那条同样是本地实测：Go 进程 RSS 约 2.56GiB，Rust/Tokio 约 0.36GiB。
问题不在数字，在「换了语言，所以快了 X 倍」这个归因。
文章算了道残忍的算术题：一个 500 毫秒的接口，火焰图显示 CPU 逻辑只占 30 毫秒，剩下 470 毫秒是网络和磁盘 I/O。假设 AI 把整个服务翻成 Rust，把 CPU 部分快足 30 倍，用户感知的接口耗时也只变成 471 毫秒、提升不到 6%。那 470 毫秒的等待根本不在乎调用方是 Python 还是机器码。知乎
更启发人的是操作系统大神 Bryan Cantrill 的真事：他把自己当年精心手写的 C 程序重写成 Rust，快了整整 30%，而带来这场性能飞跃的不是 Rust 的语法，是从链表到 B-Tree 的数据结构重构——当年写 C 他图省事用了链表，换 Rust 才用上了对缓存友好的标准库 BTreeMap。Rust 只是递了把铲子。知乎
同样的逻辑也适用于那些「重写后快 10 倍、100 倍」的商业案例：敢重写第二版，是因为团队早已摸清瓶颈，顺手干掉了 N+1 查询、加上了批处理和缓存。把这些架构重构原样搬回 Python 和 Ruby，往往能拿到八到九成的性能收益，根本不用换语言。当然，这是原作者的经验估算，供参考，不是承诺。知乎
那 Rust 到底该用在哪？先打开火焰图
Rust 真正占优的是两类场景：真吃 CPU 的（解析、索引、压缩这类热路径），真吃内存的（常驻进程、高并发等待、上千个小沙箱）。本周被追捧的「Rust 侧车」模式就是聪明解法：界面和胶水留给 TypeScript，重活外包给 Rust 引擎。小红书有开发者晒出 3890页/秒、219MB内存的 Rust 爬虫引擎，主要面向 AI 和 RAG 应用。知乎也有人用 Rust 重写的 PGX 让一台机器并发跑上千个隔离数据库，不再为每个智能体起一整个容器。这一批的共性是：谁都没把整个应用逐行翻译，只把最重的那块活接走。小红书知乎
真正该警惕的是另一种操作：把一坨烂设计逐行翻译成 Rust，然后以为问题解决了。AI 时代「重写」的成本降到了地板，结果只会得到一个内存极其安全的慢软件。知乎
所以下次刷到「用 Rust 重写后快 X 倍」，先问一句：原来那 500 毫秒里，CPU 占几毫秒？
让计算机少做不必要的工作——这八个字，不会因为换了语言、加了 AI 就过期。
