从 Go 迁移到 Rust

func (s *Service) Handle(req *Request) error {
    // Find 返回 (*User, error)。当找不到用户时 error 是 nil；
    // 调用方应检查 user != nil，但这很容易被遗忘。
    user, err := s.repo.Find(req.UserID)
    if err != nil {
        return err
    }
    return user.Account.Notify() // 如果 user 为 nil 或 Account 为 nil 则崩溃
}

fn handle(&self, req: &Request) -> Result<(), ServiceError> {
    let user = self.repo.find(req.user_id)?;   // 返回 Option<User>；? 操作符会在 None 时短路并返回错误
    user.notify()
}

#[derive(Debug, thiserror::Error)]
pub enum UserError {
    #[error("user {0} not found")]
    NotFound(UserId),
    #[error("user already exists")]
    AlreadyExists,
    #[error(transparent)]
    Repo(#[from] RepoError),
}

pub fn rename(id: UserId, name: &str) -> Result<User, UserError> {
    let mut user = repo::get(id)?;        // ? 自动将 RepoError 转换为 UserError
    user.name = name.to_string();
    Ok(user)
}

func ReadConfig(path string) (*Config, error) {
    data, err := os.ReadFile(path)
    if err != nil {
        return nil, fmt.Errorf("reading config: %w", err)
    }
    var cfg Config
    if err := json.Unmarshal(data, &cfg); err != nil {
        return nil, fmt.Errorf("parsing config: %w", err)
    }
    return &cfg, nil
}

fn read_config(path: &Path) -> Result<Config, ConfigError> {
    let data = fs::read_to_string(path)?;
    let cfg = serde_json::from_str(&data)?;
    Ok(cfg)
}

func GetUser(id string) *User {
    for _, u := range users {
        if u.ID == id {
            return &u
        }
    }
    return nil
}

u := GetUser("123")
fmt.Println(u.Name) // 如果为 nil 则 panic

fn get_user(id: &str) -> Option<User> {
    users.iter().find(|u| u.id == id).cloned()
}

let user = get_user("123");
println!("{}", user.name); // 编译错误：`user` 是 Option<User>，而不是 User
// 你必须处理两种情况：
match get_user("123") {
    Some(u) => println!("{}", u.name),
    None    => println!("not found"),
}

type Reader interface {
    Read(p []byte) (n int, err error)
}

pub trait Reader {
    fn read(&mut self, buf: &mut [u8]) -> std::io::Result<usize>;
}

impl Reader for MyType {
    fn read(&mut self, buf: &mut [u8]) -> std::io::Result<usize> { /* ... */ }
}

tokio::spawn(async move {
    do_work(input).await;
});

func (s *Service) Fetch(ctx context.Context, id string) (*User, error) {
    return s.client.Get(ctx, "/users/"+id)
}

pub async fn fetch(&self, token: CancellationToken, id: &str) -> Result<User, FetchError> {
    tokio::select! {
        _ = token.cancelled() => Err(FetchError::Cancelled),
        res = self.client.get(&format!("/users/{id}")) => res,
    }
}

ch := make(chan int, 10)
go func() {
    ch <- 42
}()
v := <-ch

let (tx, mut rx) = tokio::sync::mpsc::channel::<i32>(10);
tokio::spawn(async move {
    tx.send(42).await.unwrap();
});
let v = rx.recv().await.unwrap();

type Circle struct {
    Radius float64
}

func (c Circle) Area() float64 {
    return math.Pi * c.Radius * c.Radius
}

pub struct Circle {
    pub radius: f64,
}

impl Circle {
    pub fn area(&self) -> f64 {
        std::f64::consts::PI * self.radius * self.radius
    }
}

fn greet(name: &str) -> String {
    format!("Hello, {name}")
}

*   **超 trait / 约束层次结构。** 在 Rust 中，你可以写 `trait Ord: Eq + PartialOrd`，任何满足 `T: Ord` 的类型自动满足 `Eq` 和 `PartialOrd`。Go 没有等价的机制；你只能通过嵌入接口来堆叠约束，但约束求解器不会像 Rust 的 trait 系统那样对层次结构进行推理。
*   **关联类型。** Rust 的 `Iterator` 有 `type Item;`，因此 `T::Item` 是一个可以在边界中命名的一流类型。Go 最接近的等价物是一个额外的类型参数，它会泄漏到每个签名中。
*   ** blanket 实现。** 在 Rust 中，`impl<T: Display> ToString for T` 自动为每个 `Display` 类型提供一个 `to_string()` 方法。Go 没有办法从定义包外部为类型添加方法，无论该类型是否为泛型。
*   **带有自己类型参数的方法。** 这是 Go 中一个明确的、[已记录的](https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#No-parameterized-methods) 非特性。你不能写 `func (s Set[T]) Map[U](f func(T) U) Set[U]`[3](https://corrode.dev/learn/migration-guides/go-to-rust/#fn-generic-methods)。在 Rust 中，在泛型类型上使用泛型方法是很常见的。

其实际后果是，一旦你的抽象需要“一个适用于任意 `T` 并具备这些操作的函数”之外的功能，Go 就会把你推回使用 `any` 加类型断言、代码生成或运行时反射。

### [类型推断在函数边界处停止](https://corrode.dev/learn/migration-guides/go-to-rust/#type-inference-stops-at-the-function-boundary)

Rust 使用一种类似 Hindley-Milner 的推断引擎，能够将类型信息传播到整个表达式中，包括跨越闭包、迭代器链和 `?` 操作符。你通常可以这样写：

`let evens: Vec<_> = (0..100).filter(|n| n % 2 == 0).collect();`

编译器会从范围中推断出 `_` 是 `i32`，并从 `collect` 目标推断出 `Vec<_>` 是 `Vec<i32>`。[4](https://corrode.dev/learn/migration-guides/go-to-rust/#fn-iterator-readability)

Go 的推断则浅得多。它通常可以从函数参数中推断出类型参数，但[无法从返回位置上下文中推断](https://go.dev/blog/type-inference)，无法像 Rust 那样通过泛型构建器链式推断，并且经常迫使你在调用点显式指定类型参数：

`result := slices.Collect[int](iter)  // 通常必需`

在 Rust 中这是例外情况；而在 Go 中这仍很常见。

### [单态化 vs GC 形状模板化](https://corrode.dev/learn/migration-guides/go-to-rust/#monomorphization-vs-gc-shape-stenciling)

泛型没有免费午餐：你必须在编译时、运行时付出代价，或者放弃特化（稍后会进一步讨论）。C++ 和 Rust 通过单态化在编译时付出代价。Java 则通过类型擦除加上 JIT 在运行时付出代价。Go 选择了中间路线，采用 [GCShape 模板化和字典](https://go.googlesource.com/proposal/+/refs/heads/master/design/generics-implementation-gcshape.md)：共享“GC 形状”的类型共享同一个编译后的函数，并通过运行时字典进行调度。

Go 的选择保持了编译时间快速，这是一个真实而宝贵的属性。代价是泛型 Go 代码可能比等效的手写非泛型版本明显更慢，因为每个类型参数上的方法调用都经过一次间接访问。有一篇[著名的 PlanetScale 文章](https://web.archive.org/web/20220331073738/https://planetscale.com/blog/generics-can-make-your-go-code-slower)清楚地展示了这一点。

Rust 会进行单态化：每个 `Vec<i32>` 和 `Vec<String>` 都会产生专门的机器码，零运行时调度。泛型代码是 _最快_ 的路径，而使用 `dyn Trait`（相当于 Go 的接口调度）是一种你希望获得运行时多态性时做出的刻意选择。你为单态化付出的是编译时间，这正是 C++ 数十年来一直在支付的代价。这两种权衡都不是显然正确的；它们只是针对不同的目标进行了优化。

### [它们不会掩盖类型系统中的漏洞](https://corrode.dev/learn/migration-guides/go-to-rust/#they-don-t-plaster-over-holes-in-the-type-system)

这是我最困扰的部分。

一个好的泛型系统应该 _消除_ 使用逃生舱（escape hatches）的理由。在 Rust 中，泛型 + trait 消除了大多数你原本需要 `Box<dyn Any>` 或运行时反射的情况。类型系统变得更强大。

在 Go 中，泛型并没有消除 `any`，也没有消除 `reflect`，也没有消除代码生成作为 ORM、解码器和 mock 等场景的主要模式。`encoding/json` 仍然使用反射。`database/sql` 仍然使用 `any`。`mockgen` 仍然生成代码。真正需要泛型系统发光发热的地方，正是 Go 在 1.18 之前就依赖运行时机制的地方。

Go 中的泛型感觉是附加的，是工具箱中一个新的工具，仅在狭窄情况下有用。而 Rust 中的泛型则感觉是基础性的；如果去掉它们，语言就会崩溃。

这就是区别所在，也是我经验中泛型 Go 代码读起来并不比它所取代的基于 `interface{}` 的代码更好，只是读起来不同，多了更多标点符号。

## [流行的 Go 包及其对应的 Rust 版本](https://corrode.dev/learn/migration-guides/go-to-rust/#popular-go-packages-and-their-rust-counterparts)

| 关注点 | Go | Rust |
| --- | --- | --- |
| HTTP 服务器 | `net/http`, `chi`, `gin`, `echo`, `fiber` | `axum`（基于 `hyper`） |
| HTTP 客户端 | `net/http`, `resty` | `reqwest` |
| gRPC | `google.golang.org/grpc` + `protoc-gen-go` | `tonic` + `prost` |
| OpenAPI (代码生成) | `oapi-codegen` | `utoipa`（代码优先）或 `openapi-generator` |
| SQL | `database/sql`, `sqlc`, `sqlx`, `gorm` | `sqlx`, `sea-orm`, `diesel` |
| 数据库迁移 | `golang-migrate`, `goose` | `sqlx migrate`, `refinery` |
| JSON | `encoding/json`, `sonic`, `goccy/go-json` | `serde` + `serde_json` |
| 日志记录 | `log/slog`, `zerolog`, `zap` | `tracing` + `tracing-subscriber` |
| 指标监控 | `prometheus/client_golang` | `metrics` + `metrics-exporter-prometheus` |
| 配置管理 | `viper`, `koanf` | `config`（config-rs），`figment` |
| 命令行工具 | `cobra`, `urfave/cli` | `clap`（派生宏） |
| 数据验证 | `go-playground/validator` | `validator` |
| 错误处理 | `errors`, `pkg/errors` | `thiserror`（库），`anyhow`（二进制程序） |
| 测试 | `testing`, `testify`, `gomega` | 内置 `#[test]`, `rstest`, `assert_matches` |
| 模拟测试 | `mockgen`, `moq` | 手写模拟（惯用方式），`mockall` |
| HTTP 模拟测试 | `httptest` | `httpmock`, `wiremock-rs` |
| 测试中的真实依赖 | `testcontainers-go` | `testcontainers` |
| 重试/退避机制 | `cenkalti/backoff` | `backon` |
| 后台任务 | goroutines + `errgroup` | `tokio::spawn` + `JoinSet` |

如果你已经对 Go 有偏好，那么 Rust 生态系统也达到了类似的“默认选择”水平。对于典型的后端服务来说：`axum` + `sqlx` + `tokio` + `tracing` + `serde` + `clap` 能覆盖你所需的 90% 功能。

## [转向 Rust 的主要挑战](https://corrode.dev/learn/migration-guides/go-to-rust/#key-challenges-in-transitioning-to-rust)

我在这里要坦率地说。从 Go 转向 Rust，你会遇到一个“**墙**”。这个“墙”是有名字的。

### [借用检查器](https://corrode.dev/learn/migration-guides/go-to-rust/#the-borrow-checker)

Go 的运行时为你处理了内存管理和别名问题。而 Rust 将这些决策推到了类型系统中。在最初的几周里，你可能会写出“显然应该能工作”的代码，但编译器却拒绝它。

最容易让 Go 开发者受挫的模式包括：

1.   **长期引用**。在 Go 中，你可以长时间持有来自 map 的 `*User` 指针。而在 Rust 中，这种借用会阻止整个生命周期内对该 map 的修改。通常的解决方法是克隆，或者更严格地限制借用的作用域。
2.   **自引用结构体**。在 Go 中很常见（一个结构体同时包含数据和其上的迭代器）。在 Rust 中，这需要使用 `Pin`、`ouroboros` 或重新设计。几乎总是：重新设计。
3.   **跨 goroutine 共享可变状态**。你在 Go 中写的 `mu sync.Mutex; data map[K]V` 在 Rust 中变成了 `Arc<Mutex<HashMap<K, V>>>`。虽然稍微啰嗦一些，但检查更严格。
4.   **函数返回引用**。[生命周期标注](https://corrode.dev/blog/lifetimes/) 出现了。它们并没有听起来那么糟糕，但确实是新的概念。

有了这些规则，借用检查器听起来像是某种“守门员”，不断阻碍你，让人感到沮丧。但这并不是学习 Rust 时应有的心态。借用检查器真正揭示的是你代码中存在的实际且非常严重的 bug，如果不加以解决，程序就会面临安全问题。因此，每当 `rustc` 给出编译错误时，请停下来思考一下你的代码可能如何出错。你可以问自己几个问题：

*   如果一个值从一个地方“被移动”到另一个地方，如果原始位置再次尝试使用它会发生什么？
*   如果一个值在多个线程之间共享，如果一个线程在另一个线程使用它时修改了它会发生什么？
*   如果一个指针被“解引用”，如果它是空指针或悬垂指针会发生什么？
*   当一个值“离开作用域”时，如果它还在其他地方被使用会发生什么？

这就是你需要理解借用检查器的心态。人类在推理内存方面确实很糟糕。我们容易忘记指针可能是空的，旧的引用可能比其所指向的数据存活得更久，以及多个线程可能同时访问同一份数据。我们倾向于用一种“线性”的思维模型来理解数据在程序中的流动，但实际上它更像是一个复杂的图，包含许多路径和交互。每一个 `if` 条件都迫使你考虑两个分支的情况。每一个循环都迫使你考虑每一次迭代的情况。而这正是借用检查器为你设计的推理方式！它在编译期强制执行最佳实践，当你自己的思维模型与借用检查器冲突时（而后者通常是正确的 99% 时间），它可能会让你觉得烦人。确实存在借用检查器过于严格的场景，但这种情况很少见，作为初学者你几乎不会遇到。我在早期也多次在内存管理上犯错，但我以“学习者的心态”去面对，这帮助我问“我的代码哪里错了？”而不是“编译器哪里错了？”，这也是我在培训中经常看到的反应。

好消息是，一旦你掌握了借用的概念，它就不会再与你作对了。大多数经验丰富的 Rust 开发者都会告诉你，借用检查器在第 4 到第 12 周之间逐渐变成了他们的盟友。第一个月是最难熬的。PubNub 的 Stephen Blum 在最近的一次播客中很好地描述了这段经历：

> 当你开始深入学习时：是挫败感。它让我想起了第一次学编程时的感觉，因为差别太大了。面对借用检查器和生命周期，我不想处理这些东西——但我不得不这么做。
> 
> 
> —— Stephen Blum，PubNub 首席技术官，在 [Rustacean Station](https://rustacean-station.org/) 上

以下是 Ed Page（`clap` 的维护者）对这条曲线另一端的看法，这也是你应该优化的目标：

> 编译器借用检查器帮我避免了去思考这些问题，让我能够专注于更高层次的问题。它在我自己分析并失败时帮助我发现了问题。
> 
> 
> — Ed Page，在 [Rustacean Station: clap with Ed Page](https://rustacean-station.org/)

### [编译时间](https://corrode.dev/learn/migration-guides/go-to-rust/#compile-times)

对你团队诚实一点，Rust 的编译时间确实比 Go 差很多。一个中型服务的干净发布构建可能需要几分钟，而 Go 几乎是即时编译。增量构建和 `cargo check` 是合理的，而且这些年编译时间已经大大改善，但你仍然会感受到这种差异。

为了缓解这个问题，请在编辑循环中使用 `cargo check`，一旦收益明显就拆分成工作区，并将过程宏密集的 crate 放在自己的 crate 中，这样它们只会在更改时重新编译。想深入了解可以查看 [加快 Rust 编译时间的技巧](https://corrode.dev/blog/tips-for-faster-rust-compile-times/)。

### [异步着色](https://corrode.dev/learn/migration-guides/go-to-rust/#async-coloring)

正如 [Goroutines 与 Async Tasks](https://corrode.dev/learn/migration-guides/go-to-rust/#goroutines-vs-async-tasks) 中所讨论的那样，Rust 的 `async fn` / `fn` 分离是从 Go 迁移过来最大的人体工程学退步之一。自 Rust 1.75 起，异步 trait 已经稳定，但在与动态分发混合时仍存在一些棘手的问题，有时你会需要用到 `async-trait` crate 来掩盖这些问题。

### [某些细分领域生态系统较小](https://corrode.dev/learn/migration-guides/go-to-rust/#smaller-ecosystem-in-some-niches)

Rust 的 crate 生态系统正在增长，且整体库质量很高，但在一些后端相关领域，Go 有先发优势：Kubernetes operator、云提供商 SDK、特定小众数据库驱动。在你做出承诺之前，花一天时间检查你依赖的库是否有你愿意使用的 Rust 对应版本。我帮助的团队通常至少需要自己手动实现一到两个核心库。例如，他们可能需要更新一个已废弃的用于 XML schema 验证的 crate，或者为一个不太知名的协议编写自己的客户端。

## [集成策略](https://corrode.dev/learn/migration-guides/go-to-rust/#integration-strategies)

你不必一次性重写所有内容。我在播客上听到的所有成功的 Go 到 Rust 的迁移故事都是战术性的，而不是一次性的大改。来自微软的 Victor Ciura 表达得很清楚：

> 我们并不是疯狂地全面转向 Rust，只是为了好玩而重写所有东西。我们做的是战术性选择，我们会说：“好吧，这个新组件，用 Rust 来做更好。”
> 
> 
> — Victor Ciura，微软首席工程师，在 [Rust in Production](https://corrode.dev/podcast/s04e01-microsoft)

最有效的策略，按我通常推荐的顺序如下：

### [1. 将热点路径作为服务分离出来](https://corrode.dev/learn/migration-guides/go-to-rust/#1-carve-off-a-hot-path-as-a-service)

如果你的集群中有一个特定的服务一直是问题所在（高 CPU 使用率、对延迟敏感或频繁出现可靠性问题），那就只把它用 Rust 重写，同时保持相同的 API 合约。这是风险最低的迁移方式。其他 Go 服务继续通过 HTTP/gRPC 与其通信，对底层语言一无所知。Radar 的 Jeff Kao 描述了 Discord 的著名帖子是如何成为团队尝试的动力：

> 如果你在 Hacker News 上搜索“迁移到 Rust”，第一个结果总是关于 [Discord 从 Go 迁移到 Rust](https://discord.com/blog/why-discord-is-switching-from-go-to-rust) 的文章。这几乎激励我们去尝试 [是否也能做到同样的事情]。
> 
> 
> — Jeff Kao，Radar 首席技术官，在 [Rust in Production](https://corrode.dev/podcast/s05e08-radar)

### [2. 替换一个 Sidecar / Worker 进程](https://corrode.dev/learn/migration-guides/go-to-rust/#2-replace-a-sidecar-worker-process)

后台工作者、队列消费者、数据摄入管道和 CPU 密集型批处理作业是非常好的首选目标。它们通常具有清晰的输入/输出边界（一个队列、一个主题），并且与系统的其余部分没有共享的进程内状态。

### [3. cgo 可行但痛苦](https://corrode.dev/learn/migration-guides/go-to-rust/#3-cgo-is-possible-but-painful)

你可以通过 cgo 从 Go 调用 Rust，[有很好的指南介绍如何操作](https://blog.arcjet.com/calling-rust-ffi-libraries-from-go/)。（如果你对此感兴趣，可以联系我，我可以为你提供相关指南。）实际上，我很少建议在后端服务中使用这种方法。相比“直接启动一个 Rust 服务并通过网络调用”而言，构建复杂性和 FFI 开销通常得不偿失。对于库和 CLI 工具来说，这种方式更可行。

### [4. 在网关后使用 Strangler 模式](https://corrode.dev/learn/migration-guides/go-to-rust/#4-strangler-pattern-behind-a-gateway)

如果你有一个 API 网关或反向代理，你可以将特定端点路由到新的 Rust 服务，而其余部分仍留在 Go 中。当一个有界上下文（认证、搜索、计费）是合适的迁移单位时，这种方法特别有效。这个模式通常被称为 [“绞杀树”](https://martinfowler.com/bliki/StranglerFigApplication.html)，因为新服务围绕旧服务逐渐成长，最终完全取代它。

## [实用迁移技巧](https://corrode.dev/learn/migration-guides/go-to-rust/#practical-migration-tips)

**从具有明确边界的某个服务开始。** 不要选择你集群中最中心、部署最多的那个服务。选择一个与系统其余部分契约定义良好且影响范围较小的服务。

**保持相同的 API 合约。** 如果你的 Go 服务暴露了一个 REST API，那么你的 Rust 服务也应当如此：相同的路径、相同的 JSON 结构、相同的错误封装。迁移对客户端来说是不可见的，你可以通过网关逐步切换流量。

**不要逐字翻译习语。** 避免写出带有 Go 风格的 Rust 代码。`if err != nil { return err }` 应该改为 `?`。每个请求一个 goroutine 的模式只有在真正需要时才使用 `tokio::spawn`（因为 axum 已经可以并发处理请求）。只有一个方法的接口通常会变成泛型上的 trait bound，而不是 `Box<dyn Trait>`。

**把编译器当作你的编程伙伴。** Rust 编译器的报错信息通常非常清晰。慢慢阅读这些错误信息。它们几乎总是告诉你正确的解决方案。那些在学习过程中挣扎最久的团队成员，往往是那些与编译器对抗而不是将其视为合作者的人。

**尽早投资培训。** 我见过一些团队试图“边做边学”地进行 Rust 迁移。这很少有好结果。这就像报名参加马拉松比赛后才开始跑步训练一样。你当然可以做到，但过程会很痛苦，而且可能无法完成。安排专门的时间用于学习：工作坊、[在线课程](https://course.corrode.dev/)、真实代码上的结对练习。一旦团队熟练掌握，前期投入将会得到数倍回报。（嘿，如果你想要聊聊培训选项，[我很乐意交流](https://corrode.dev/services)。）

## [保持 Go 的优势](https://corrode.dev/learn/migration-guides/go-to-rust/#keeping-go-s-strengths)

并非所有内容都应迁移到 Rust。Go 在以下方面表现出色：

*   **原生 Kubernetes 工具链**：operator、controller、CRD。生态系统主要由 Go 构成。
*   **命令行工具和开发工具**：快速编译、易于交叉编译、部署简单。
*   **胶水服务**：轻量级 API 层、代理、格式转换器。在 Rust 中写样板代码并不值得。
*   **任何团队效率比绝对正确性更重要的地方**。

这不是一个边缘立场。对于同时大规模使用这两种语言的公司来说，这个观点更加明显：

> Go 是网络服务非常好的选择。我们在 Canonical 大量使用 Go——Juju 就是一个庞大的 Go 代码库。
> 
> 
> —— Jon Seager，Canonical 工程副总裁，在 [Rust in Production](https://corrode.dev/podcast/s05e05-canonical)

混合策略是完全可以接受且常见的。我合作过的许多团队最终采用了多语言后端架构：Go 用于“平凡”的服务，而 Rust 用于那些可靠性与性能回报更高的场景。

## [预期改进](https://corrode.dev/learn/migration-guides/go-to-rust/#expected-improvements)

具体数字因负载不同而差异很大，所以请将这些作为大致参考。不是承诺！但基于我协助过的 Go 到 Rust 迁移项目，这里是一些粗略数据：

*   CPU 使用率：减少 20–60%。不如 Python 到 Rust 那么显著，因为 Go 本身已经高效。收益主要来自没有 GC 和更紧凑的循环。

*   内存使用：减少 30–50%，主要是由于没有 GC 开销以及运行时更小。

*   P99 延迟：显著更稳定。Rust 服务往往表现平滑，而 Go 服务则会出现明显的 GC 导致抖动。（自从 Go 引入低延迟 GC 后情况已大大改善，但在高负载下仍存在差异。）

*   生产事故：这是团队报告最多兴奋的方面。那些能绕过 `go test -race` 并进入生产环境的 bug 类型（数据竞争、空指针解引用、遗漏错误路径）在 Rust 中根本无法编译通过。Rust 迁移之后，值班轮岗通常变得非常无聊。Andrew Lamb 在 InfluxDB 重写后描述了这种效果：

> 我不再需要追踪崩溃、奇怪的多线程竞态条件，或者消耗我大量时间的其他问题。
> 
> 
> —— Andrew Lamb，InfluxData 高级工程师，在 [Rustacean Station: Rebuilding InfluxDB with Rust](https://rustacean-station.org/)

说实话，从 Go 转到 Rust 不像从 Python 转换那样能获得 10 倍的吞吐量提升。你得到的是更少的“愚蠢错误”和更平坦的延迟尾部，以及在保持同一语言的前提下扩展到嵌入式开发或系统编程领域的能力。这常常是迁移带来的最令人惊讶的效果：以前必须使用不同技术栈的团队现在可以共享代码。你可以用 Rust 做一切。

## [结论](https://corrode.dev/learn/migration-guides/go-to-rust/#conclusion)

从 Go 转向 Rust 是一种不同于从 [Python](https://corrode.dev/learn/migration-guides/python-to-rust) 或 [TypeScript](https://corrode.dev/learn/migration-guides/typescript-to-rust) 转换的迁移方式。从 Go 出发，你已经了解静态类型和编译型语言的优势。因此你并不是放弃动态类型或慢速运行时，而是用更健壮的代码库替代 `nil`，减少潜在陷阱，并采用一个更严格的编译器来在编译期捕获更多错误。不过，这也意味着更高的学习曲线。

对于 [基础服务](https://corrode.dev/blog/foundational-software/)（组织依赖的服务、高可用性要求、业务关键性的服务），这种权衡显然是值得的。而对于其他服务，Go 仍然是正确的选择。迁移的核心在于将每个问题交给最适合解决它的语言。

我帮助后端团队评估、规划并执行 Go 到 Rust 的迁移。无论你需要架构审查、培训，还是需要帮助移植关键服务，[让我们谈谈你的需求](https://corrode.dev/services)。

1. Rust 的类型系统并不能捕获所有的数据竞争，但那些在没有同步机制的情况下根本无法在线程间共享的类型将无法通过编译。你仍然可能在同步逻辑中存在错误，但不会再出现“哎呀，我忘了给这个加锁”这类问题，而这类问题常常导致无声的数据损坏。[↩](https://corrode.dev/learn/migration-guides/go-to-rust/#fr-races-1)

2. 值得澄清一下，因为这会让很多人困惑：Go 中的 `string` 是一个不可变的 _字节_ 序列，通常（但不保证）是有效的 UTF-8 编码。`rune` 是一个 Unicode 码点（即 `int32` 的别名），当你对 `string` 进行 range 操作时得到的就是它。`[]byte` 是一个可变的字节缓冲区。最接近的一对一映射是：`string`（Go）↔ `&str`（Rust）用于只读视图，`[]byte`（Go）↔ `Vec<u8>`（Rust）用于可变缓冲区。Rust 中的 `String` 是 `&str` 的所有者版本，且可增长，并额外保证其内容是有效的 UTF-8（而 Go 的 `string` 在类型层面并不强制这一点）。更多信息请参见 [Go 中的字符串、字节、符文和字符](https://go.dev/blog/strings)。[↩](https://corrode.dev/learn/migration-guides/go-to-rust/#fr-go-strings-1)

3. 准确地说，这指的是除了接收者类型外还引入了 _其自身_ 类型参数的方法。Go 自 1.18 起就支持泛型 _函数_ 和泛型类型，因此 `func Map[T, U any](s []T, f func(T) U) []U` 是完全合法的。但你不能将这个 `Map` 作为泛型 `Set[T]` 的方法来实现，并让调用者在每次调用时指定 `U`。Go 的提案明确地回避了这个问题，而且至今仍未加入该特性。[↩](https://corrode.dev/learn/migration-guides/go-to-rust/#fr-generic-methods-1)

4. 如果你来自 Go 语言，那行代码需要一点时间去理解：`(0..100)` 是一个惰性范围（lazy range），`.filter(|n| ...)` 是一个闭包（`|n|` 是参数列表，对于单个表达式不需要大括号），而 `.collect()` 将迭代器转换为左侧所要求的类型。Go 并不是一种特别函数式的语言，这种迭代器链的写法确实是一种需要适应的风格，而惯用的 Rust 非常依赖这种风格，在最初的几周可能会有些陌生。当然，你仍然可以在 Rust 中使用 `for` 循环，对于一次性使用的代码这通常是正确的选择，但一旦熟悉之后你会发现迭代器模式会变得非常自然，而且能够无中间变量地链式转换，这在你掌握后会显著提升代码的可读性。（至少这是我的体验。）[↩](https://corrode.dev/learn/migration-guides/go-to-rust/#fr-iterator-readability-1)