用Rust重写我那个C语言版的Redis克隆，比任何教程都更能教会我Rust

---

如果你跟我一样，喜欢通过“从头造轮子”来理解系统，那你大概率干过这种事：用C写一个Redis克隆——RESP解析器、命令表、AOF持久化，一套下来几百行代码，感觉对键值存储的理解直接拉满。

最近我又干了一件事：用Rust把同一个项目重写了一遍。结果呢？这次重写教会我的Rust知识，比之前任何“从零开始学Rust”的教程都要多得多。

原因其实很简单：第二次做的时候，设计已经解决了。我知道AOF必须保证什么、命令表怎么分发、解析器要拒绝什么。所以我的注意力完全不用放在“做什么”上，而是全放在“Rust希望我怎么把它做出来”上。

这就相当于把“领域知识”变成了常量，把“语言”变成了唯一的变量。每遇到一个差异，都是Rust给我的纯信号，而不是键值存储本身的噪声。

---

第一波差异：标准库决定了你的起点

第一个差异在写任何业务逻辑之前就出现了。

在C版里，我先得造基础设施：自己实现动态字符串、自己写哈希表、自己搞链表。几百行代码下去，一个命令都还没跑起来。

而在Rust里，Vec、String、HashMap直接拿来就用。整个基础设施层直接消失，我从真正的命令逻辑开始写。

一个标准库，悄无声息地决定了你的项目从哪开始。

这不是说C不好——C的生态就是这样，你得自己搞定一切。但当你从C切到Rust，第一个感受就是：原来语言自带的东西，能让你少写这么多样板代码。

---

第二波差异：编译器就是你的代码审查员

更尖锐的差异在命令分发上。

C里我是这么干的：

if (argc != 3) return err("wrong arg count");

switch (cmd) {
    case CMD_SET:
        return do_set(argv[1], argv[2]);
    case CMD_GET:
        return do_get(argv[1]);
    // 少写一个case？那就是一个运行时bug
}

你看，注释里我特意写了“少写一个case就是运行时bug”。这不是开玩笑——我真的在生产环境里因为漏掉一个case而出过bug。C的switch不会管你，它只会静默地什么都不做，然后你花两个小时debug才发现少了某个命令。

Rust里同样的分发逻辑是这样：

match cmd {
    Command::Set { key, val } => self.set(key, val),
    Command::Get { key } => self.get(key),
    // 少写一个case？编译器直接拒绝编译
}

一样的逻辑。但一个版本不可能带着漏掉的case上线——因为我真的试过，编译器直接给我报错：“pattern Command::Del not covered”。

这就是Rust的核心哲学：把运行时错误变成编译时错误。

你可能会说“这不就是枚举+模式匹配吗？有什么了不起的？”但当你真的从C切过来，亲手感受到编译器拦住了你曾经踩过的坑，那种感觉是完全不一样的。它不是教条，是实实在在帮你省时间。

---

更深层的：所有权和生命周期开始“咬”我

上面两个差异其实还是比较表面的。真正让我学到东西的，是Rust的所有权系统在AOF持久化这块给我的“教育”。

C里实现AOF很简单：每条写命令执行完后，打开文件，写入命令文本，flush，关闭。指针传来传去，谁都能读写，只要你不free太早或者忘记free，一切正常。

Rust里呢？我一开始也是同样的思路：Store结构体里有一个Vec<u8>作为写缓冲区，然后set方法里拿到key和val，往缓冲区里写。

但问题来了：key和val是String，而set方法需要同时修改Store里的数据（HashMap）和缓冲区（Vec）。Rust的借用检查器告诉我：你不能同时可变借用两个东西，即使它们完全不相干。

第一次遇到这个错误的时候我是懵的。在C里这根本不是问题——两个指针各指各的，随便写。但Rust不让你这么干。

后来我查了资料才明白：编译器看到的不是“两个不同的字段”，而是“同一个结构体的两个可变引用”。解决方案是拆分结构体，或者用RefCell做内部可变性。

我最后选择了拆分：把AOF缓冲区单独拿出来，在函数里先完成数据操作，再单独写AOF。这其实也符合更好的架构设计——写AOF不应该和数据操作混在一起，只是C从来不会强迫你思考这件事。

---

再说说错误处理

C里错误处理是这样的：

int ret = do_set(store, key, val);
if (ret != 0) {
    // 打印错误，或者返回错误给客户端
    return send_error(client, "ERR something went wrong");
}

每个函数返回一个int，0表示成功，非0表示各种错误。但问题是：这个int到底代表什么？ 是内存分配失败？参数错误？文件写入失败？你得自己定义错误码，自己维护一个错误码表，而且很容易漏掉某个分支。

Rust里用Result<T, E>：

fn set(&mut self, key: String, val: String) -> Result<(), Box<dyn Error>> {
    // 如果这里出错，用 ? 操作符直接传播
    self.aof.write_entry(&format!("SET {} {}\r\n", key, val))?;
    self.data.insert(key, val);
    Ok(())
}

?操作符让我不用写一堆if (ret != 0) { return ret; }。更重要的是，错误的类型是显式的——如果函数返回Result<(), IoError>，调用者就知道只能遇到I/O错误，不会突然冒出一个“索引越界”之类的东西。

这种显式性在调试时帮了大忙。有一次AOF写入失败，Rust的?直接把底层的Os { code: 28, kind: StorageFull }一路传上来，我一眼就知道是磁盘满了。在C里，同样的错误可能被我包装成ERR_WRITE_FAILED，然后还得再查日志才知道具体原因。

---

总结：如果你真想学一门语言，就重写一个你熟悉的东西

这次重写让我意识到一件事：教程教你的是语法，重写教你的是思维方式。

• 你熟悉了C的“一切皆指针”，Rust的所有权系统才会让你真正理解“谁拥有这块内存”为什么重要。
• 你写过C的switch-case漏掉分支的bug，才会感激Rust的match必须穷举所有可能。
• 你手动管理过C的内存泄漏和double free，才会觉得Rust的借用检查器不是限制，而是保护。

所以我的建议是：如果你正在学Rust（或者任何新语言），找一个你已经用另一种语言完整实现过的项目，重写一遍。不要选新项目，因为新项目会让你同时思考“这个功能怎么设计”和“这个语言怎么用”两个问题。

把设计变成常量，把语言变成变量。然后，你就能真正感受到这个语言的设计哲学——而不仅仅是它的语法糖。

---

附：我写C版Redis clone时的一些数据——大约1200行C代码，包括自定义的哈希表、动态字符串、RESP解析器。Rust版大约800行，因为标准库帮我省掉了基础设施层。AOF持久化在C里花了大概150行，Rust里用了std::fs::OpenOptions和write!宏，不到50行。性能上两者差不多，但Rust版的错误处理路径我更有信心——因为编译器替我检查过了。