原文

很多人刚学 Rust 时，写代码是这样的流程：

想逻辑 → 写函数 → 被编译器骂 → 改到能过

但当你写 Rust 写到一定阶段，会突然发现自己的顺序变成了：

先想类型 → 再想状态 → 最后才写逻辑

而且更诡异的是：
一旦类型设计对了，代码几乎是“顺着写出来的”。

这不是偶然，这是 Rust 在长期使用中，对你思维方式的重塑。

1️⃣ 在 Rust 里，“类型”本身就是一部分逻辑

在很多语言中，类型只是：

• 帮助 IDE 自动补全
• 防止把 string 传给 int
• 跑的时候反正还能改

但在 Rust 里，类型直接参与了程序正确性的表达。

举个非常普通的例子。

其他语言里的状态表达

status = 0 / 1 / 2

配合注释：

0 = init
1 = running
2 = closed

Rust 写久了的人会怎么写？

enum State {
    Init,
    Running,
    Closed,
}

然后你会更进一步：

struct Machine<S> {
    state: S,
}

因为你意识到：
状态不是一个值，而是一种“能力集合”。

2️⃣ 类型不是“数据结构”，而是“约束集合”

Rust 中一个非常关键但常被忽略的认知转变是：

struct / enum 并不是为了存数据，而是为了限制“你能怎么用这些数据”。

一个经典例子：ID vs 原始类型

新手 Rust：

fn get_user(id: u64) -> User

写久了的 Rust：

struct UserId(u64);

fn get_user(id: UserId) -> User

为什么？

• 防止把 OrderId / BlockHeight / Timestamp 传进来
• 为未来约束留钩子（范围、合法性、来源）
• 在类型层面建立“语义边界”

你开始用类型隔离概念，而不是靠人脑记忆。

3️⃣ Rust 会逼你回答：这个值“是谁拥有的”？

在 GC 语言里，所有权是模糊的：

• 谁都能拿
• 谁都能改
• 谁负责释放？“反正 GC 会收”

Rust 不允许这种暧昧。

当你设计一个类型时，你必须想清楚：

• 它是被 拥有 的，还是被 借用 的？
• 它会不会被 移动？
• 能不能 共享？
• 能不能 并发访问？

于是你会发现：

struct Context {
    cache: Cache,
}

和

struct Context<'a> {
    cache: &'a Cache,
}

不是实现细节，而是系统架构选择。

你不是在选语法，而是在选：

• 资源生命周期
• 模块边界
• 并发模型

4️⃣ “先设计类型”的本质：把决策前移到编译期

写久了 Rust，你会越来越讨厌这种代码：

fn process(x: Option<Data>) {
    if x.is_none() {
        return;
    }
    let x = x.unwrap();
    // ...
}

不是因为它不能跑，而是因为：

合法性检查被推迟到了运行期。

你会更愿意写：

fn process(x: ValidData) {
    // 根本不需要检查
}

于是系统发生了一个重要变化：

• 错误更早暴露
• 调用路径更清晰
• 测试压力降低
• 重构成本下降

Rust 的类型系统，其实是一台编译期决策引擎。

5️⃣ enum 是 Rust 中最被低估的“架构工具”

很多语言的 enum 只是常量集合。
Rust 的 enum，是代数数据类型（ADT）。

enum Event {
    Connected { peer: PeerId },
    Disconnected { reason: Reason },
    Message { data: Bytes },
}

这意味着：

• 每个分支可以携带不同数据
• match 必须覆盖所有情况
• 新增分支会强制你修改所有处理点

你不再害怕“忘记处理某种情况”，因为编译器会替你盯着。

当系统开始复杂，你会发现：

enum + match
比 if/else + flag
更接近“系统真实结构”。

6️⃣ trait 的真正作用：定义“能力边界”，而不是复用代码

很多人把 trait 当成“接口”。
但在 Rust 里，它更像是：

一组你承诺满足的能力约束。

fn run<T: Send + Sync + 'static>(t: T)

这不是在说“我需要一个 T”，而是在说：

• 可以跨线程
• 生命周期独立
• 不依赖外部借用

当你设计 trait 时，你其实在设计：

• 哪些能力是必须的
• 哪些是可选的
• 哪些应该被隐藏

于是你会开始拆 trait：

trait Read {}
trait Write {}
trait Flush {}

而不是一个巨型 trait。

这是架构层面的设计，而不是语法技巧。

7️⃣ 当你“类型设计对了”，代码会出现一个明显特征

这个特征是：

match 很少失败，if 很少兜底，unwrap 几乎消失。

因为：

• 不合法的状态已经无法构造
• 不满足条件的路径在类型层面被剪掉
• panic 成为“真正的 bug”，而不是控制流的一部分

你会发现代码开始呈现一种奇怪的“顺畅感”：

• 函数很短
• 分支很少
• 错误路径很清晰

这不是你变强了，是类型在替你思考。

8️⃣ Rust 最深的设计哲学之一：让“不确定性显性化”

Rust 讨厌这些东西：

• 隐式 null
• 隐式共享
• 隐式生命周期
• 隐式状态转换

于是它用：

• Option
• Result
• 生命周期参数
• typestate
• enum

把所有“不确定性”变成：

你必须面对、必须写出来、必须处理的东西。

这也是为什么很多人会觉得 Rust：

• 啰嗦
• 严格
• 写得慢

但当系统规模扩大后，你会发现：

Rust 只是把你迟早要付的代价，提前收了。

结语：当你开始“先设计类型”，你就跨过了一道 Rust 分水岭

从这一刻开始：

• 你写代码不再急着写逻辑
• 你会先画出 enum / struct / trait
• 你会问：“非法状态能不能被构造？”
• 你会把错误路径当成一等公民

这通常也是一个信号：

你已经不再把 Rust 当成一门语言，而是在把它当成一个“系统设计工具”。