Go 和 Rust 性能谁更快？一次 HTTP 实测告诉你差距在哪里

bigfish — Sun, 11 Oct 2026 23:18:00 +0800

Go 和 Rust 做同一个 HTTP 服务，谁能处理更多请求？这次实测的答案不是一句“Rust 更快”就能概括：在 5,000 个连接下，Rust 的固定文本吞吐高 78.2%，JSON 序列化高 85.8%；但把主要工作换成固定 CPU 计算后，两端只差约 1%。连接数继续增加，Go 的默认配置还会先遇到 OOM，而设置内存软上限后，问题又变成延迟超标。

这篇文章整理一次 Go 与 Rust HTTP 服务的公平复测，重点看四件事：

在相同资源和负载下，吞吐与 P99 尾延迟差多少；
JSON 工作是否会放大两套实现的差异；
更多连接是在提高并发，还是只是在制造排队；
Go 的内存策略改变后，原本的 OOM 结论还是否成立。

先把结论说窄：在本次 1 个逻辑 CPU、512 MiB 内存的测试环境中，Rust 版本在轻量 HTTP 和 JSON 场景中明显领先；固定 CPU 计算场景则几乎打平。Go 在高连接数下的默认配置会 OOM，但设置 GOMEMLIMIT=384MiB 后，15,000 连接可以稳定完成测试，20,000 连接仍然超过延迟目标。

这些结论只适用于本次实现、依赖、负载和运行环境，不能直接变成“Rust 在所有服务中都比 Go 快”的语言排名。

为什么 Rust 的无栈协程是异步 I/O 的技术最优解？

bigfish — Wed, 07 Oct 2026 15:48:15 +0800

Go 可以在普通调用链深处挂起 goroutine，让线程去处理其他工作。Rust 为什么没有采用同样的方式，却要求开发者显式写出 async/await，还要面对 Future、Pin 和执行器？

本文要论证的是：在大量任务都等待网络的异步 I/O 场景中，Rust 的无栈协程可以称为技术最优解。 这里的“最优”不是跑分意义上的全面胜出，而是指它同时解决了三个核心问题：等待中的任务不必各自占用一份可挂起的协程栈，异步操作可以组合，执行路径又能由编译器直接生成状态机。

这里的“技术最优解”有明确范围：比较的是等待任务的内存占用、可组合性、执行效率、运行时耦合和资源边界。无栈协程省掉的是每个等待任务的专属协程栈，不是 Future 状态、连接和缓冲区本身；它也不是宣称所有负载下都最快。CPU 密集计算、长时间阻塞调用和需要透明暂停的场景，仍然可能适合线程或有栈协程。后文会先解释这些方案分别保存什么，再说明为什么这组取舍在异步 I/O 中占优。

bigfish的网络博客 - Go

Go 和 Rust 性能谁更快？一次 HTTP 实测告诉你差距在哪里

为什么 Rust 的无栈协程是异步 I/O 的技术最优解？