"Rust for high stakes, Go for low costs." —— Bitfield Consulting, 2026
这个问题每年都有人问，每年都有新答案。作为一个用 Go 写了四年生产服务、最近又把核心模块迁移到 Rust 的后端开发者，我想用真实的项目经验给你一个不带滤镜的对比。
不是"哪个更好"，而是"什么时候该用哪个"。
先说结论
| 场景 | 推荐 | 理由 | | --- | --- | --- | | 高并发微服务 | Go | goroutine 天生适合，开发快 | | 计算密集型 | Rust | 零成本抽象，无 GC 停顿 | | 创业公司 MVP | Go | 一周上手，三周出活 | | 基础设施/嵌入式 | Rust | 内存安全是刚需 | | 团队 < 5 人 | Go | 招人容易，学习曲线低 | | 性能天花板要压到极致 | Rust | 没有 GC 的上限就是更高 |
下面展开说。
性能：数据说话
2026 年初的 TechEmpower Round 23 基准测试和多个独立评测给了我们很清晰的数据：
HTTP 服务吞吐量
框架 请求/秒 (2核) 内存占用 ───────────────────────────────────────── Rust Actix-web ~160K req/s 50-80 MB Rust Axum ~148K req/s 55-85 MB Go Gin ~95K req/s 100-320 MB Go Fiber ~105K req/s 95-280 MB
Rust 在吞吐量上大约领先 Go 1.5-1.7 倍，内存占用低 2-4 倍。
这个差距在你日请求量只有几千的时候可以忽略。但如果你跑的是每秒几万请求的核心链路，Rust 省下来的内存和 CPU 就是实打实的服务器成本。
CPU 密集型任务
在 Fibonacci、JSON 解析、二叉树遍历等 CPU 密集测试中，Rust 通常是 Go 的 2 倍快：
// Rust: 计算 Fibonacci 第 40 项 fn fib(n: u64) -> u64 { match n { 0 => 0, 1 => 1, _ => fib(n - 1) + fib(n - 2), } } fn main() { let start = std::time::Instant::now(); let result = fib(40); println!("fib(40) = {}, 耗时: {:?}", result, start.elapsed()); // ~22ms (AMD EPYC) }
// Go: 同样的计算 package main import ( "fmt" "time" ) func fib(n uint64) uint64 { if n <= 1 { return n } return fib(n-1) + fib(n-2) } func main() { start := time.Now() result := fib(40) fmt.Printf("fib(40) = %d, 耗时: %v\n", result, time.Since(start)) // ~39ms (AMD EPYC) }
77% 的差距。这不是微基准测试的噪音，这是 Rust 零成本抽象 + 无 GC 的真实体现。
并发模型：两种哲学
这是两者最根本的设计差异，也是你选型时最该想清楚的点。
Go：goroutine，简单粗暴
func handleRequest(ctx context.Context, req Request) error { // 开 3 个并发任务 ch := make(chan Result, 3) go func() { ch <- queryDB(req.UserID) }() go func() { ch <- fetchCache(req.Key) }() go func() { ch <- callAPI(req.Token) }() // 收集结果 for i := 0; i < 3; i++ { result := <-ch process(result) } return nil }
Go 的并发就是这么简单。go 关键字一加，goroutine 跑起来了，channel 收数据。一个新手看半小时文档就能写出能跑的并发代码。
Goroutine 的调度器是 M:N 模型，一个 goroutine 大约 2-8 KB 栈空间，百万级并发在合理配置下完全可行。
Rust：async/await，精确控制
use tokio; #[tokio::main] async fn handle_request(req: Request) -> Result<(), Error> { // 并发执行 3 个任务 let (db_result, cache_result, api_result) = tokio::join!( query_db(&req.user_id), fetch_cache(&req.key), call_api(&req.token), ); process(db_result?); process(cache_result?); process(api_result?); Ok(()) }
Rust 的 async 也很优雅，但底层完全不同。编译器会把 async 函数编译成状态机，零运行时开销。没有 GC，没有隐式调度，你精确控制每一个字节的生命周期。
代价呢？ 借用检查器（borrow checker）会是你前几个月最大的敌人。这段代码看着简单，但一旦涉及生命周期标注和 pin，复杂度会指数级上升。
真实项目踩坑记录
案例 1：消息队列消费者服务
我们有一个从 Kafka 消费消息、处理后写入 PostgreSQL 的服务。
Go 版本（初版）：
-
开发时间：3 天
-
代码量：~800 行
-
内存占用：~280 MB
-
P99 延迟：12ms
Rust 版本（重写版）：
-
开发时间：8 天
-
代码量：~1200 行
-
内存占用：~65 MB
-
P99 延迟：4ms
Rust 版本内存省了 77%，延迟降了 67%。但开发时间多了将近 3 倍。
我的结论：如果这个服务的流量在日均百万级以下，Go 版本就够了。省下来的 5 天开发时间比省下来的 200MB 内存值钱得多。但我们的量级是日均 5 亿条消息，Rust 版本一年省下来的服务器成本够养一个 Rust 工程师了。
案例 2：内部 API 网关
一个给内部微服务做路由、鉴权、限流的网关。
这次我直接用 Go。原因：
-
并发模型简单，goroutine-per-request 天然适合
-
团队里 4 个人都会 Go，只有 1 个人会 Rust
-
瓶颈在下游服务响应时间，不在网关本身的计算
// Go 的限流器，几行搞定 func RateLimiter(limit int, window time.Duration) gin.HandlerFunc { limiter := rate.NewLimiter(rate.Every(window/time.Duration(limit)), limit) return func(c *gin.Context) { if !limiter.Allow() { c.AbortWithStatusJSON(429, gin.H{"error": "rate limited"}) return } c.Next() } }
这种场景你用 Rust 就是杀鸡用牛刀。
编译时间：Rust 的阿喀琉斯之踵
必须提这个痛点。
项目规模 Go 编译时间 Rust 编译时间 ───────────────────────────────────────── 小型 (1K行) 1-2 秒 15-30 秒 中型 (10K行) 3-8 秒 45-120 秒 大型 (50K行) 10-20 秒 3-8 分钟
Go 的编译速度快到你可以忽略它的存在。Rust 的编译时间……你会学会在等编译的时候刷手机。
好消息是 Rust 团队一直在优化。cargo check 只做类型检查不生成二进制，能快 3-5 倍。sccache 做增量编译缓存。2026 年的 Rust 1.83 对编译速度又做了一轮优化，中型项目已经能控制在 1 分钟以内了。
生态系统：2026 年谁更强？
Go 的优势领域
-
云原生
：Kubernetes、Docker、Terraform、Prometheus……CNCF 生态大半是 Go 写的
-
Web 框架
：Gin、Echo、Fiber，成熟稳定
-
微服务工具链
：gRPC、OpenTelemetry、etcd，一等公民
Rust 的优势领域
-
系统编程
：Linux 内核已经将 Rust 从实验性升级为永久支持
-
WebAssembly
：Rust 是 WASM 的最佳拍档
-
高性能中间件
：Cloudflare Workers、Deno、Turbopack 都是 Rust
-
区块链/加密
：Solana、Polkadot 的核心
2026 年的一个大变化：Debian 从 5 月开始在 APT 包管理器中强制引入 Rust 依赖。Android 16 已经内置了 Rust 编写的内存分配器。Rust 不再是"那个难学的新语言"了，它是基础设施层的标准选择。
招人和薪资
说点现实的。
根据 2026 年的数据：
-
Rust 开发者平均薪资
：美国 $178,000（同比 +12%）
-
Go 开发者平均薪资
：美国 $165,000（同比 +8%）
差距在拉大，原因是 Rust 人才供给不足。金融、汽车、航空这些安全敏感行业疯抢 Rust 工程师。
Go 的优势是池子大。会 Go 的人多，培训成本低，一个 Java/C++ 开发者转 Go 可能就一两周的事。转 Rust？做好三到六个月的准备。
我的选型决策树
你的项目核心瓶颈是什么？ │ ├── CPU 计算 / 内存限制 / 尾延迟要求严格 │ └── → 选 Rust │ ├── I/O 密集 / 高并发连接 / 快速迭代 │ └── → 选 Go │ ├── 不确定？ │ ├── 团队 < 10 人，先出产品 → Go │ ├── 已有 Go 代码库 → 混合：热点模块用 Rust 重写 │ └── 从零开始且性能是核心卖点 → Rust │ └── 还是纠结？ └── → 先用 Go 出 MVP，跑出数据再决定要不要迁 Rust
最后一句话：Go 让你快速到达 80 分，Rust 帮你冲到 99 分。大多数业务，80 分就够了。
参考资料
-
TechEmpower Round 23 Benchmarks
-
Rust vs Go: 40% Latency Gap in 2026
-
ByteIota: Rust vs Go 2026 Backend Performance
-
Rust in Linux Kernel - Permanent Adoption
-
Bitfield Consulting: Rust vs Go
我是小军，一个喜欢折腾后端架构的独立技术博主。如果这篇文章对你有帮助，欢迎关注我的公众号「技术放肆聊」，每周更新技术干货。
