原文

如果说第一篇《Rust 进阶：你可能没真正用过的语言能力》是在告诉你：

Rust 不是“你以为会的那样”

那这一篇，我们聊的是另一件事：

当系统复杂度真的上来时，Rust 会强迫你面对哪些你在别的语言里可以逃避的问题。

不是“语法难”，也不是“生命周期反人类”，
而是——Rust 不让你模糊、不让你拖、不让你把复杂度藏起来。

1️⃣ Rust 不允许你“先写着，后面再说”：复杂度必须有归属

在很多语言里，面对复杂系统，你可以：

• 先写个类
• 塞点字段
• 传点回调
• 状态不清晰？先 if / else 顶着
• 并发问题？加把锁再说

Rust 则完全相反。

一旦你开始写下面这些东西之一：

• 多阶段状态流转
• 并发 + 异步
• 跨模块资源共享
• 生命周期超过一个函数调用

Rust 会立刻追问你：

“这些复杂度，到底是谁的责任？”

例子：一个“看似简单”的 Client

struct Client {
    conn: Option<Connection>,
    authed: bool,
}

在很多语言里，这已经够用了。
在 Rust 里，它会迅速变成噩梦：

• conn 是 None 还是 Some？
• authed 为 false 时能不能发请求？
• 谁来保证状态组合合法？

于是你被迫做选择：

• 要不要用 typestate
• 要不要拆成多个类型
• 要不要用消费式 API（self -> Self）

👉 Rust 不允许你把“系统状态”埋在布尔值里。

2️⃣ Rust 会让你意识到：并发不是“加锁”，而是“所有权的重新分配”

在其他语言里，并发往往等于：

“这个对象可能被多个线程同时用，那我加个锁。”

Rust 的第一反应却是：

“这个对象，真的应该被共享吗？”

一个非常典型的转变

你原本想写：

Arc<Mutex<State>>

写着写着你会发现：

• 锁粒度越来越大
• 调用链里到处 .lock().unwrap()
• 死锁风险开始出现
• 性能问题很难推断

然后 Rust 会给你另一条路：

• 把状态拆开
• 用消息传递
• 用所有权转移代替共享可变

enum Command {
    Update(X),
    Query(Responder),
}

你不是“学会了 Actor 模型”，
而是 Rust 让你发现：共享可变状态是复杂度的源头。

3️⃣ 生命周期的真正意义：它不是限制你，而是在描述“资源流向”

很多人第一次被生命周期打败，是因为它看起来像：

“编译器在找你麻烦”

但在复杂系统里，你会慢慢意识到：

生命周期其实是在强迫你画清楚一张图：资源从哪来，活到哪去。

一个非常现实的问题

• 这个 slice 是从缓存里借的，还是从网络 buffer 里借的？
• 能不能跨 await？
• 能不能存进 struct？
• 调用者需不需要保证它活得够久？

在其他语言里，这些靠文档、靠约定、靠经验。
在 Rust 里：

fn parse<'a>(input: &'a [u8]) -> Item<'a>

签名本身就是约束声明。

当你开始写库、写基础设施时，你会发现：

• 好的生命周期设计 = 好的 API
• 糟糕的生命周期 = 用户痛苦 + 自己也维护不下去

4️⃣ async Rust 的真相：你不是在写“并发代码”，你是在写“状态机”

很多人会说：

“Rust async 难，是因为语法不成熟。”

但真正的原因是：

Rust 没帮你隐藏状态机。

在其他语言里

• async 函数是“魔法”
• await 后面的世界是黑盒
• 引用跨 await？“别这么干就行了”

在 Rust 里

• 每个 async fn 都是一个 具体的类型
• await 点是状态边界
• 借用跨 await = 状态机里存引用 = 地址稳定问题

于是你不得不理解：

• 为什么有 Pin
• 为什么有 Unpin
• 为什么某些 Future 不能 move

这不是 Rust 折磨你，是它拒绝帮你隐瞒复杂度。

5️⃣ 错误处理：Rust 不让你忽略“失败路径的结构”

在复杂系统里，失败不是例外，而是常态：

• 网络超时
• 数据不一致
• 上游服务异常
• IO 抖动

很多语言的默认策略是：

“throw 一下，往上冒，日志里再说”

Rust 会逼你想清楚：

• 这是可恢复错误还是致命错误
• 调用者有没有能力处理
• 错误是否需要携带上下文
• 错误是否应该暴露给 API 用户

enum Error {
    Timeout,
    InvalidData { field: &'static str },
    Io(std::io::Error),
}

当错误开始有结构，你会发现：

• 日志更清晰
• 重试策略更容易写
• 系统行为更可预测

6️⃣ unsafe 出现的时刻，往往意味着：你已经在做“系统级工作”

当你写业务 CRUD，unsafe 很远。
但当你开始：

• 写 runtime
• 写高性能数据结构
• 写 FFI / 底层 IO
• 压榨极限性能

你几乎不可避免会遇到 unsafe。

Rust 的态度很明确：

你可以做，但你要负责。

这会带来一个很重要的转变：

• unsafe 不再是“偷懒”
• 而是“明确标注风险边界”
• 不变量必须被写下来
• 不安全必须被封装

你开始真正像一个系统工程师，而不是脚本作者。

7️⃣ Rust 最残酷也最公平的一点：复杂度不会消失，只会转移

Rust 的设计哲学可以总结为一句话：

复杂度要么在编译期暴露，要么在运行期爆炸。

Rust 选择了前者。

• 生命周期复杂 → 换来无 GC、无悬垂引用
• 类型复杂 → 换来非法状态不可表示
• async 难 → 换来可预测的性能与内存模型

这也是为什么：

• 小项目用 Rust 显得“重”
• 大项目用 Rust 显得“稳”

结语：Rust 不适合所有人，但它非常适合“对复杂度负责的人”

如果你只是想：

• 快速写个脚本
• 容忍偶发 bug
• 用经验兜底

Rust 可能不适合你。

但如果你正在面对：

• 高并发
• 长生命周期服务
• 基础设施
• 区块链 / 数据系统 / runtime / 网络协议

你会慢慢理解：

Rust 不是让你更快，而是让你更早面对问题。