本文永久链接 – https://tonybai.com/2026/08/18/rust-primer-introduction

大家好，我是Tony Bai。

【导读】

如果你也曾在借用检查器（borrow checker）的长篇报错前退缩过，或者曾因缺乏真实应用场景而半途而废，那么你绝不是一个人。在这篇开篇词中，Tony Bai 首次坦诚复盘了自己两次放弃 Rust 的真实经历，并深入探讨了在 AI 编程工具普及的今天，我们究竟该把 Rust 学到什么程度：我们不再需要死记硬背语法，但必须掌握对 AI 生成代码进行审查、调优、架构取舍并承担最终责任的核心能力。“事不过三”，这一次，我们将通过 4 个里程碑项目与 54 讲系统拆解，在 2024 Edition 的全新基准上，彻底攻克 Rust 这座高山。

【文章要点】

  • 两次真实失败复盘：第一次倒在 borrow checker 的概念轰炸下，第二次困于缺乏真实业务场景与持续推进的约束机制；
  • AI 时代的 Rust 价值重估：当 AI 能够廉价生成代码，追求高并发、低延迟与强安全的基础设施（Bun、Codex CLI、Linux 内核、Android）正全面加速拥抱 Rust；
  • 学习重心的根本转变：不再和 AI 比拼写代码的速度或死记语法，而是培养“读懂 → 判断 → 修改 → 验证 → 设计 → 负责”的全链路工程直觉；
  • 结构化设计与项目驱动：基于 Rust Stable 与 edition = "2024" 基准，规划 4 大进阶模块，由 4 个完整实战项目（cligrep、KV 引擎、多线程 Web 服务器、异步 Redis-like）串联；
  • 公开学习与同行监督：以全年 54 讲的节奏建立可复现的心智模型，把每一次踩坑与顿悟完全摊开。

先说一个可能有点扎心的事实：如果你点开这篇开篇词，大概率你已经不是第一次尝试学 Rust 了。你可能和我一样，电脑里还留着一两个当年写到一半就再也没打开过的 cargo new 项目。

我自己就有过两次这样的经历。

两次放弃 Rust 的真实故事

第一次，是 Rust 2021 版本前后。

那时候我兴致勃勃地打开教程，代码敲到第三天就被“借用检查器”（borrow checker）教做人。

同一个变量，明明“看起来”没什么问题，编译器却坚持说这里有一个悬垂引用、那里有一次已经被移动的值又被使用。报错信息一条比一条长，我一条比一条心虚。

所有权、借用、生命周期这三座大山几乎是同时压过来的，我当时既没有“图解内存”的直觉，也没有人告诉我“这不是你笨，是这几个概念本来就该分开、循序渐进地学”。于是这次尝试，停在了对 borrow checker 的怨气里。

第二次，是 2024 年。

这一次我认真了很多，甚至在个人博客上专门开了个系列叫“Rust第一课”，一篇一篇地记录自己的学习过程（感兴趣的话，网上还能翻到当年的痕迹）。这一轮我啃下了不少硬骨头，一路写到了 Rust 的依赖管理和项目组织。但问题出在了两个地方：一是工作中始终没有一个能落地的 Rust 场景——学了用不上，动力就会一点点被现实磨掉；二是这个系列本身缺一个“逼自己走完全程”的机制，写着写着，笔就停了。

两次尝试，两次因为不同的原因半途而废，但共同点是：都没有走到能独立做成一件事的那一步。

事不过三。这次不一样——我不再一个人闷头学，而是把学习过程完全摊开，打算用一整年（约54周）的时间，公开地、有节奏地、和一群同样“至少失败过一次”的读者一起，把 Rust 这块硬骨头啃下来。这也是“事不过三”这个专栏名字的来历：不是说我保证这次一定成功（谁也不敢打这个包票），而是这次我们有了前两次没有的东西——结构化的路径、项目驱动的节奏，以及一群互相监督的同行者。

AI 时代，我们为什么还要学好 Rust？

这几年一个很现实的声音是：“都有 AI 写代码了，我还有必要死磕一门以难学著称的编程语言吗？”

在回答这个问题之前，我想先带你重新认识一下 Rust 这门语言本身——它是怎么诞生的、骨子里想解决什么问题，这些年又经历了哪些关键节点。了解这些背景，你会发现“要不要学它”这个问题，其实早就有了答案。

一场电梯故障引发的语言

Rust 的起源，有一个在社区里流传很广的段子：2006 年，供职于 Mozilla 的程序员 Graydon Hoare 有一天回到他在温哥华的公寓，发现电梯又双叒坏了——罪魁祸首是电梯控制软件崩溃了。他住在21楼，爬楼梯爬到一半，越想越气：“我们这些搞计算机的人，怎么连一部不会崩溃的电梯软件都写不出来？”

这类崩溃背后，很多时候都是 C/C++ 这类语言里典型的内存管理问题——空指针、悬垂指针、缓冲区溢出。Hoare 由此动手，在业余时间开始设计一门新语言，这就是 Rust 最早的雏形。

这个项目最初只是他一个人的业余爱好，直到 2009 年才引起 Mozilla 内部一小群人的兴趣并开始得到官方资助，2010 年在 Mozilla 年度峰会上首次公开亮相。

经过多年打磨，2015 年 5 月 15 日，Rust 1.0 正式发布，并且立下了一个郑重的承诺——向后兼容，永不破坏，这个承诺一直延续至今，也是我们能放心用它做长期项目的底气来源。

落到具体的设计哲学上，可以概括成三个关键词：

  • 内存安全，但不要垃圾回收（用编译期检查代替运行时垃圾回收器）；
  • 零成本抽象（写高层次、易读的代码，性能要能媲美手写的底层实现，且不使用的抽象不会产生额外运行时开销）；
  • 无畏并发（编译器在编译期就帮你堵住数据竞争，让你敢于放心地写多线程代码）。

下面这张时间线，梳理了 Rust 从一个人的业余项目，成长为今天这个体量的关键节点：

回到最初的问题：为什么是现在，为什么是 Rust

认识了这门语言的来龙去脉，我们回到开头那个问题。我想用几件最近发生、还在持续发生的事情来回答它——这些事情连起来看，其实就是这张时间线在 2025-2026 年这一段的延伸和加速。

先看应用层和工具层的选择：

  • 2026 年，JavaScript 运行时 Bun 把自己从 Zig 整体重写成了 Rust，理由很直接：Rust 的内存安全模型能在编译期堵住大量“用后释放”、“重复释放”这类曾经反复折磨团队的底层 bug。
  • 同样在 2026 年，Jack Dorsey 旗下的 Block 公司开源了 Buzz——一个把人和 AI Agent 放进同一个协作空间的项目，它的核心中继服务是用 Rust 写的。
  • OpenAI 的编码 Agent 工具 Codex CLI，早在2025年初就从 Node.js/TypeScript 技术栈整体转向了 Rust，官方给出的理由包括“零依赖安装”、“原生安全沙箱能力”和更好的性能表现。
  • 再往前看，ClickHouse 这样的老牌高性能数据库开始引入 Rust 组件。

再看更硬核的系统基础设施层，变化更加实打实：

  • 2026年，Rust 在 Linux 内核中的地位继续提升，并逐步进入更多生产级系统软件和基础设施场景。Android 16 搭载的 Linux 6.12 内核也进一步扩大了 Rust 在生产环境中的实际应用。
  • Google 根据 Android 平台的真实生产数据估算，Rust 代码的内存安全漏洞密度相比历史 C/C++ 代码低超过三个数量级（1000 倍以上）。
  • Cloudflare 已在多个核心基础设施项目中广泛采用 Rust，包括 Pingora、quiche 等高性能网络组件，以提升性能、安全性和内存安全。
  • Debian APT 项目也在推进对 Rust 的采用，并计划将 Rust 引入部分基础设施组件。这意味着，在 Debian 生态中，Rust 正逐渐成为基础设施的一部分。

最后，再来横向对比一下其他后端编程语言：

最新的 GitHub 2026 数据（https://guenhter.github.io/githubstats/）显示，2026年6月，Rust 在 Star 增速等维度上延续了近几年的强劲势头，与 Java、Go 之间的差距肉眼可见地在缩小——具体到某些统计口径下，甚至出现了阶段性反超的迹象。这背后反映的，是行业对内存安全和系统级性能的需求正在持续升温。

这些不是孤立事件，串起来看是一个很清楚的信号：当行业进入“AI 大规模生成代码”的阶段，那些追求高性能、高并发、强安全边界的基础设施层，反而更加需要 Rust。

原因也不难理解——AI 能帮你更快地“写出”代码，但内存安全、数据竞争、资源生命周期这类问题，本质上考验的是“你对系统底层的理解有多深”，这恰恰是 AI 目前最容易“一本正经写错”、也最需要人来审查和负责的地方。会用 AI 写 Rust，和看得懂、改得动、敢负责地上线 Rust 代码，是两种完全不同的能力。

更有意思的是，AI 时代也在悄悄补齐 Rust 曾经最大的短板——学习曲线陡峭、报错信息难啃。以前你对着一屏幕生命周期报错抓耳挠腮，现在你可以让 AI 帮你逐行拆解报错原因、给出修复建议，再回过头去对照本专栏讲的原理搞懂“为什么”。这种“AI 辅助 + 系统化学习”的组合，是我们这次和前两次相比，最大的外部优势。这也是本专栏想帮你把握住的机会。

AI 时代，我们究竟要把 Rust 学到什么程度？

说到这里，一个更现实的问题来了。

如果 AI 已经可以帮我们写 Rust 代码，甚至可以根据一句自然语言描述，直接生成一个能编译、能运行的 Rust 项目，那么我们还需要像过去一样，从头到尾把 Rust 的语法一个字母一个字母地背下来吗？

不需要。

但这不等于“不需要学习 Rust”。

恰恰相反，AI 时代改变的不是“要不要学编程语言”，而是我们学习一门编程语言，应该把能力的重心放在哪里。

过去，一个程序员需要花大量时间记忆语法、API 和各种样板代码；今天，这些事情越来越可以交给 AI。

但有几件事情，反而变得更加重要。

第一，你要能读懂 AI 写出来的 Rust

AI 给你一段代码，你不能只看着 cargo build 通过，就认为它是正确的。

你至少应该能看懂：

  • 这个值的所有权现在属于谁？
  • 这里为什么需要借用？
  • 这个生命周期为什么成立？
  • 这个 Arc<Mutex<T>> 为什么要这样设计？
  • 这个 async 代码有没有隐藏的并发问题？
  • 这个 unsafe 到底绕过了什么安全保证？

这些问题的共同点是：它们不是“代码长什么样”的问题，而是“这段代码为什么这样写”的问题。

第二，你要能判断 AI 写得对不对

这是 AI 时代非常容易被低估的一项能力。

AI 最危险的地方，并不是它不会写代码，而是它经常能够写出看起来非常像正确答案的代码。

尤其是 Rust。

一段代码可能：

能编译
    ↓
能通过测试
    ↓
甚至能正常运行

但仍然可能存在：

  • 错误的所有权设计
  • 不必要的 clone
  • 不合理的 Arc/Mutex
  • 过度复杂的生命周期
  • 不恰当的 unsafe
  • 错误的并发模型
  • 不合理的错误处理

所以，未来程序员真正稀缺的能力，不一定是“谁写代码最快”，而是：

谁能更快地判断一段 AI 生成的代码到底值不值得相信。

第三，你要能修改 AI 写不对的地方

AI 很擅长从已有模式生成代码，但真实项目往往没有标准答案。

当你遇到一个 Rust 编译错误时，你不能永远只把错误信息复制给 AI，然后等待下一版答案。

你应该逐渐建立这样的能力：

你不一定需要自己从零写出每一行代码，但你应该知道哪一行值得改、为什么改、改完以后应该验证什么。

第四，你要能够做架构和取舍

这是我认为 AI 时代学习 Rust 最值得保留的一部分。

当你真正面对一个项目时，问题通常不是：

“这个函数应该怎么写？”

而是：

“这里应该拥有数据，还是借用数据？” “这里应该返回 Option 还是 Result？” “这里需要 Box 吗？” “这个状态应该用 Arc<Mutex<T>>，还是换一种并发模型？” “这个 trait 应该使用泛型静态分发，还是 dyn Trait 动态分发？” “这个模块应该公开什么 API？” “这里为了性能牺牲一点代码复杂度，值得吗？”

这些决策，才是真正决定一个 Rust 项目质量的地方。

AI 可以给你方案，但你需要有能力理解方案背后的所有权、类型系统、并发模型、性能和可维护性，然后做出选择。

所以，如果一定要给“AI 时代应该把 Rust 学到什么程度”画一条线，我会这样划：

不需要：

  • 背诵所有语法
  • 记住所有 API
  • 手写所有样板代码

但必须逐渐做到：

能读懂 → 能解释 → 能调试 → 能修改 → 能验证 → 能做设计取舍 → 最终能对 AI 生成的代码负责

这就是我认为 AI 时代学习 Rust 最值得达到的程度。

我们不是要和 AI 比谁写代码更快。我们真正要做的是：

让自己成为那个知道“该让 AI 写什么、为什么这样写、怎么判断它写得对不对，以及出了问题该怎么改”的人。

所以，这个专栏不会要求你把每一行代码都手敲一遍，更不会要求你背诵 Rust 的全部语法。但我会要求你逐渐建立一套属于自己的 Rust 心智模型。 因为代码可以让 AI 写，但理解、判断和负责，暂时还不能外包。

这一次，我准备怎么讲

结合前两次失败的教训，这个专栏在设计上刻意做了几件事：

  • 螺旋式上升，而不是一次性堆知识点。 所有权、生命周期这些硬骨头，不会指望你第一次见就吃透，而是初期“建立直觉”、中期“结合项目深入应用”、后期“回顾拔高”，符合真实的认知规律。
  • 项目驱动，而不是零散的知识点罗列。 全年会有四个完整项目串起来——命令行工具、KV 存储引擎、多线程 Web 服务器、异步 Redis-like 服务器，每一个都要求你把前面学的东西真正用起来。
  • 对齐当下的 Rust，而不是几年前的教程。 本专栏统一基于 Rust Stable 与 edition = "2024" 编写，并以当前稳定版为基准持续校验代码；会把这两年真正稳定下来的重要新特性（比如 let-else、let 链、异步闭包）用到该用的地方，而不是回避它们。
  • 公开的学习日志，而不是端着的专家讲座。 我会把自己踩过的坑、卡住的地方原样写出来，而不是假装我一路顺风顺水。

下面这张图，是这一年四个模块、四个里程碑项目的整体路线图，先建立一个全局印象：

课程内容大纲策划（完整目录）

全年 54 讲，分成四个阶段，一次性列给你，方便你一目了然，也方便你随时回来对照进度：

模块一：基础与核心概念重建

  • 01 | 开篇词：事不过三，我们为什么总是学不好 Rust？
  • 02 | 工具箱：打造一个“劝退不了”的 Rust 开发环境
  • 03 | Cargo实战：从 cargo new 到依赖管理与 Workspace
  • 04 | 语法地图（上）：变量、数据类型与函数——Rust 代码长什么样
  • 05 | 语法地图（下）：用 if / loop / for 表达“控制流即表达式”
  • 06 | 所有权：从“一把钥匙”的故事说起
  • 07 | 图解内存：Stack vs. Heap，彻底搞懂 Move 和 Copy
  • 08 | 借用与引用：图书馆的“借阅”规则
  • 09 | 可变借用：为什么 Rust 只允许“一个写者”？
  • 10 | 生命周期初探：编译器眼中的“悬垂指针”
  • 11 | 结构体中的生命周期：为你的数据“担保”
  • 12 | ‘static 与省略规则：让编译器为我们“打工”
  • 13 | 综合练习：亲手实现一个 String::Split 功能
  • 14 | Struct 与 Enum：用代数数据类型优雅地建模
  • 15 | Option 与 Result：告别 Null，拥抱安全的错误处理
  • 16 | Match 与 if let：Rust 模式匹配的威力
  • 17 | 模块化：用 Module 组织你的代码
  • 18 | 项目一：构建一个命令行 Grep 工具 (cligrep)

模块二：抽象与表达能力

  • 19 | 泛型：编写适用于多种类型的代码
  • 20 | Trait (上)：定义共享行为的“契约”
  • 21 | Trait (下)：Trait Bound 与 Derive 的魔法
  • 22 | Trait 对象：Rust 中的动态分发
  • 23 | 闭包：捕获环境的匿名函数
  • 24 | 迭代器：用函数式风格处理序列
  • 25 | 深入迭代器：实现你自己的 Iterator Trait
  • 26 | 性能对决：迭代器 vs. 传统 for 循环
  • 27 | Box：将数据强制分配在堆上
  • 28 | Rc 与 Arc：共享所有权的“引用计数”
  • 29 | RefCell 与 Mutex：“内部可变性”模式
  • 30 | 解引用 Deref Trait 与 Drop Trait
  • 31 | 错误处理进阶：thiserror 与 anyhow
  • 32 | 单元测试、集成测试与文档测试
  • 33 | 项目二：实现一个简单的 In-memory KV 存储引擎

模块三：并发与系统级编程

  • 34 | 线程与消息传递：用 Channel 在线程间安全通信
  • 35 | 共享状态并发：Mutex 与同步原语
  • 36 | Send 与 Sync Trait：编译器如何保证线程安全？
  • 37 | 项目三：构建一个多线程 Web 服务器
  • 38 | Unsafe Rust：打开潘多拉魔盒
  • 39 | FFI：在 Rust 中调用 C 语言函数
  • 40 | FFI：将 Rust 代码编译为可供 Python/Go 调用的库
  • 41 | 宏编程入门：声明式宏 macro_rules!
  • 42 | 过程宏初探：编写自己的 #[derive]
  • 43 | 生命周期再探：高级生命周期、HRTB 与 RPIT 捕获规则

模块四：异步编程与生态探索

  • 44 | 异步编程：为什么需要 async/await？
  • 45 | Future Trait：异步世界的“期货合约”
  • 46 | 异步闭包与 AsyncFn：async || {} 是怎么补上的最后一块拼图
  • 47 | Tokio 运行时：驱动你的 Future
  • 48 | 异步中的所有权：Pin 与 Unpin
  • 49 | Web 开发：使用 Axum/Actix-web 构建 Web API
  • 50 | 数据库交互：使用 sqlx 与 Diesel
  • 51 | 序列化与反序列化：serde 的威力
  • 52 | 项目四：构建一个支持异步的 Redis-like 服务器
  • 53 | Rust 2024 Edition 回顾与 2027 Edition 前瞻
  • 54 | 结课篇：事已过三，我们现在是 Rustacean 了！

本讲小结

这一讲没有代码，只有一句掏心窝子的话：这个专栏的存在，本身就是我“赌上第三次”的证明。

我们回顾了两次半途而废的真实经历——一次倒在 borrow checker 面前，一次倒在“缺乏落地场景+缺乏机制约束”面前；也聊了聊为什么在 AI 已经能帮你写代码的今天，Rust 反而变得更重要——从 Bun、Buzz 到 Codex CLI，行业里追求高性能和强安全边界的基础设施，正在一个接一个地转向 Rust；同时 AI 也在反过来帮我们补齐 Rust 最陡峭的那段学习曲线。

但更重要的是，我们重新定义了一下“AI 时代学 Rust”这件事：不是和 AI 比谁写代码更快，也不是把所有 Rust 语法都背下来，而是逐渐获得读懂、判断、修改、验证和设计 Rust 代码的能力，最终能够对 AI 生成的代码负责。

最后，我把这一年 4 个模块、54 讲、4 个里程碑项目的完整地图摊在了你面前——没有藏着掖着，你可以现在就判断这条路值不值得走一遍。

如果你也和我一样，曾经在所有权报错前打过退堂鼓，或者曾经学到一半因为“用不上”而放下——没关系，那两次不是失败，是这一次的铺垫。真正的学习从来不是一条直线，螺旋式地回来，只要这次能走完全程，之前的每一次尝试都没有白费。

事不过三，这一次，我们一起把它学完、学扎实。下一讲，我们先把开发环境这第一道坎，彻底、干净地迈过去。

关于订阅

写到这里，聊几句实在的——这个专栏值不值得你付费订阅。

这一次和我之前那些 3～10 多讲规模的微专栏不太一样：全年 54 讲，从所有权讲到异步并发，中间穿插 4 个完整项目，按周更新，会写满一整年。这个体量，如果按我之前微专栏的单讲定价折算，价格会相当可观——但我不打算这么算。

专栏定价 ¥99，一次订阅，覆盖全年 54 讲，后续更新不再额外收费。折算下来，单讲成本不到 2 元，比我之前任何一个微专栏都更划算——这是我特意压低的价格，不是因为内容量小，恰恰是因为内容量大：一年的更新周期，对你来说也是一份需要押注的信任，我希望订阅这件事本身，门槛越低越好。

事不过三，这一次，我们把这一年一起走完。

注：此外老规矩，本专栏在我的知识星球同步更新，加入星球便可以免费阅读！

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。