上一篇我们搞清了 TypeScript 的立场：一个在代码运行前工作的静态检查器。但有个问题悬而未决——浏览器根本不认识 .ts 文件，你的类型注解要送到哪里去？

答案是 tsc，TypeScript 编译器。它像一位身兼两职的翻译官：第一职是安检——在翻译前把你的稿子从头到尾审一遍，发现”类型用错了”就当面指出；第二职才是翻译——把 TypeScript 代码转写（transform）成等价的 JavaScript，让你能真正跑起来。有意思的是，这两项职责是解耦的：安检发现了问题，翻译照做不误；你还可以指定”翻译成哪个年代的 JavaScript”。本篇就把这两条线都走一遍。

一、初识 tsc：一场”什么都没发生”的仪式

先安装再开跑：

1
npm install -g typescript

进入空文件夹，写下第一个 TypeScript 程序 hello.ts：

1
2
// Greets the world.
console.log("Hello world!");

没错——它和 JavaScript 写法一模一样，没有任何花哨的东西。运行 tsc hello.ts，控制台一片寂静，什么也没输出。这是因为它没发现类型错误，自然无话可说；但回头一看，目录里多了个 hello.js——这就是编译产物，内容几乎和源文件相同。

这里藏着一个容易被忽略的设计目标：tsc 努力输出”看起来像人写的”干净代码——缩进一致、尊重换行、尽量保留注释。它不是把你的代码搅碎重排，而是做一次礼貌的转写。

那么，如果代码真有问题呢？把 hello.ts 改成：

1
2
3
4
5
6
// This is an industrial-grade general-purpose greeter function:
function greet(person, date) {
  console.log(`Hello ${person}, today is ${date}!`);
}

greet("Brendan");

再跑 tsc hello.ts，这次命令行报错了：

Expected 2 arguments, but got 1.

注意一个细节：到目前为止我们写的全是标准 JavaScript，一个类型注解都没加，但类型检查照样抓出了漏传参数的 bug。这就是上一说的延续——TypeScript 的检查能力从 JavaScript 代码本身的形状开始生效。

二、带错也照常输出：TypeScript 的核心价值观

刚才的例子还有个更微妙的现象：虽然报了错，hello.js 依然被更新了。查错归查错，翻译照做。

这不是 bug，而是 TypeScript 的一条核心价值观：大多数时候，你比 TypeScript 更清楚自己在干什么。最典型的场景是从 JavaScript 迁移到 TypeScript：代码本来跑得好好的，一转成 .ts 冒出一堆类型错误，难道迁移就该让程序停下来吗？不该。所以 tsc 默认”报错但不拦路”。

当你想更严格时，有一条开关可用：

1
tsc --noEmitOnError hello.ts

加上这个标志后，只要存在类型错误，hello.js 就永远不会被更新。两种策略的取舍如下：

三、显式类型与推断：什么时候该写注解

回到 greet，给它补上类型：

1
2
3
function greet(person: string, date: Date) {
  console.log(`Hello ${person}, today is ${date.toDateString()}!`);
}

: string 和 : Date 叫类型注解（type annotations），读作”greet 接收一个 string 类型的 person 和一个 Date 类型的 date”。有了它，TypeScript 立刻能发现另一处调用错误：

1
greet("Maddison", Date()); // 报错！

这个报错相当反直觉——Date() 不就是造日期吗？还真不是。不带 new 直接调用 Date() 返回的是字符串，要拿到 Date 对象必须写 new Date()。没有类型系统时，这个坑要等运行时才炸；现在编辑器当场标红。

不过 Handbook 紧接着泼了盆”别过度”的冷水：

1
2
let msg = "hello there!";
//  ^? 鼠标悬停可见类型是 string

即使不写注解，TypeScript 也能推断（infer）出 msg 是 string。它的建议很明确：如果类型系统推出来的结果和你打算写的注解一模一样，那就别写了——注解应该用在你需要”说出意图”的地方（比如函数参数），而不是给每个变量都贴标签。

四、类型擦除与降级编译：注解去了哪

把带注解的 greet 交给 tsc，输出是：

1
2
3
function greet(person, date) {
  console.log("Hello ".concat(person, ", today is ").concat(date.toDateString(), "!"));
}

和源码相比有两处变化，各代表一条重要机制：

变化一：注解全部消失。person: string 变回了 person。因为类型注解不是 JavaScript（严谨地说是 ECMAScript）的一部分，没有任何浏览器能直接运行它——这正是 TypeScript 需要编译器的根本原因：把 TypeScript 特有的代码剥掉或转写掉。大多数 TS 特有代码都会被这样”擦除”（erased）。Handbook 为此给出了一句值得抄在显眼处的备忘：

记住：类型注解永远不会改变程序的运行时行为。

这句话是理解 TypeScript 性质的钥匙——它加的是”安检”，不是”发动机”。指望用类型做运行时校验（比如校验接口返回值）是常见误区。

变化二：模板字符串被改写成 .concat() 拼接。这是降级编译（downleveling）：把新版 ECMAScript 的语法改写成旧版（如 ES3/ES5）能跑的形式。默认 target 是 ES5——一个极其古老的版本。可以用 --target 指定：

1
tsc --target es2015 hello.ts

输出就保留了原生模板字符串。Handbook 顺带提醒：绝大多数现代浏览器都支持 ES2015，除非要兼容古老浏览器，否则放心把 target 设为 ES2015 或更高。

五、严格性旋钮：从”开关”到”旋钮”

最后一个话题是所有 TypeScript 项目的灵魂设置。不同用户对检查器的期待不同：

• 有人要宽松：类型可选、推断取最宽松的类型、不检查 null/undefined——这是默认体验，专为”别挡我的路”设计，迁移老项目时是理想的起点；
• 有人要严格：让 TypeScript 一开始就尽力验证一切。

关键洞察在于：严格性不是一个开关，而是一个旋钮。拧得越紧，TypeScript 替你检查得越多，代价是需要额外的工作——但长期看是划算的，还能换来更精确的工具支持。新代码库应当始终把严格检查打开。

tsconfig.json 里的一句 "strict": true（或命令行的 --strict）能同时拧开所有严格选项，也可以逐个单独关闭。其中最重要的两个：

any 的问题说得再直白些：用了它，TypeScript 对那个值就”失明”了——检查和补全都失效，用得越多，用 TypeScript 的意义越少。

实践建议

1. 新项目一律 "strict": true：这是 Handbook 的原话级建议（”新代码库应当始终开启严格检查”）。迁移老项目可以先默认宽松跑通，再逐步拧紧旋钮。
2. 注解写在”刀刃”上：函数参数、公开 API 边界处写注解；局部变量交给推断。判断标准很简单——推出来的类型和你要写的一样吗？一样就删掉注解。
3. 记牢两个”反直觉”：Date() 返回字符串、类型注解不影响运行时行为。前者是日常 bug 源，后者决定了”运行时校验请用 zod 之类的库，别指望类型系统”。

小结

本篇揭开了编译器的面纱：tsc 是安检员兼翻译官——检查代码类型，并把 .ts 转写成 JS；默认”报错也照常输出”体现的是”你比它更懂”的价值观，--noEmitOnError 可以关掉这份宽容。类型注解在编译时被擦除，永远不改变运行时行为；旧语法会被降级编译成 target 版本可跑的形式。最后，严格性是旋钮不是开关，strict 一键全开，noImplicitAny 堵住 any 的暗门，strictNullChecks 管住”十亿美元的错误”。

下一篇进入干货最密的《Everyday Types》上篇：string/number/boolean、数组、声名狼藉的 any、变量注解，以及函数类型的写法。

这是本系列的最后一篇，也是《Rust 程序设计语言》的最后一章。前二十一篇笔记里，所有权、借用、trait、生命周期、并发、模式匹配轮番登场，但都停留在「知识点」层面——而第 20 章是毕业考试：只靠标准库，手写一个多线程 Web 服务器。

书里特意交代了一个细节：crates.io 上有大量生产级 Web 框架，我们这样做不是最佳实践，而是学习。因为 Rust 是系统编程语言，你可以选择抽象层次——自己写 HTTP server 和线程池，才能看懂将来用的 crate 背后的通用理念。就像练厨艺先不点外卖：外卖能吃饱，但只有亲手颠勺才知道火候是什么。

整个项目分三阶段演进，每一步都踩在前面的知识点上：

一、单线程服务器：40 行代码看懂 HTTP

Web 服务器的两个主角协议：TCP（底层，描述信息如何从一台机器到另一台）和 HTTP（构建于 TCP 之上，定义请求和响应的内容）。两者都是请求-响应协议——客户端发起，服务端监听并回应。我们要做的，就是处理这些「原始字节数据」。

第一步只需要标准库的 std::net：

1
2
3
4
5
6
7
8
9
use std::net::TcpListener;

fn main() {
    let listener = TcpListener::bind("127.0.0.1:7878").unwrap();
    for stream in listener.incoming() {
        let stream = stream.unwrap();
        handle_connection(stream);
    }
}

几个易忽略的细节：7878 在九宫格电话键盘上打出来就是 “rust”（这是选端口的彩蛋）；incoming 迭代的其实是连接尝试而非连接本身（系统可能限制同时打开的连接数）；handle_connection 里的 stream 必须是 mut——TcpStream 内部会缓存读取的多余数据，读操作也需要可变性，这点很反直觉。

handle_connection 用 1024 字节的缓冲区读入请求后打印，就能看到浏览器发来的原始 HTTP 请求：请求行 GET / HTTP/1.1（方法 + URI + 版本，以 CRLF 即 \r\n 结尾）+ 一堆 header。手写响应同样简单——"HTTP/1.1 200 OK\r\n\r\n" 这个微型字符串写回流里，浏览器就不再报错；再配合 fs::read_to_string 把 hello.html 塞进 body，用 Content-Length 标头声明长度，一个真正的 HTML 页面就渲染出来了。

最后用 buffer.starts_with(b"GET / HTTP/1.1\r\n") 区分 / 与其他请求（后者返回 404），并做一次经典重构：把 if/else 收缩为只返回元组 ("HTTP/1.1 200 OK", "hello.html")，再用模式解构赋值，读文件和写响应的代码只保留一份。重复代码消失了，两种情况的差异一目了然。

二、线程池：编译器驱动的开发

单线程服务器的致命弱点用一个 /sleep 请求（休眠 5 秒）就能验证：先请求 /sleep 再请求 /，后者要干等 5 秒——因为服务器串行处理连接，慢请求把队伍全堵死了。

最朴素的修复是每个连接 thread::spawn 一个新线程，但这会无限制创建线程——千万级请求打过来直接耗尽资源，这就是拒绝服务（DoS）攻击。所以答案是线程池：固定数量的线程预先待命，新请求进入队列，空闲线程认领任务，处理完继续待命。可以并发处理 N 个请求（N 为线程数）。

有意思的是开发方式：书里先写出假想的调用方代码（ThreadPool::new(4) + pool.execute(闭包)），再让 cargo check 的编译错误一步步指导实现——作者称之为编译器驱动开发。因为线程池与 Web 服务器业务无关，还被拆进了独立的库 crate（src/lib.rs），主程序挪到 src/bin/main.rs。

实现中藏着三个关键决策：

1. execute 的闭包 bound 抄谁？ 抄 thread::spawn 的签名：F: FnOnce() + Send + 'static——任务只执行一次所以 FnOnce，要跨线程转移所以 Send，不知道线程跑多久所以 'static。
2. 谁来领任务？ ThreadPool 不直接存线程，而是存 Worker（每个 Worker 包着一个 JoinHandle）——类比餐馆厨房的员工：先上岗，等订单来了再做菜。因为标准库只能「创建线程即给代码」，而我们需要「先创建线程，后发代码」，这层封装必须自己做。
3. 任务怎么发？ 用第 16 章的 mpsc 通道充当任务队列。但直接把 receiver 传给多个 Worker 会报 E0382——通道是多生产者、单消费者的。解法是 Arc::new(Mutex::new(receiver))：Arc 让多个 Worker 共享 receiver 的所有权，Mutex 保证一次只有一个 Worker 取任务。

Job 的定义是第 19 章类型别名的实战应用：type Job = Box<dyn FnOnce() + Send + 'static>;——把闭包装箱成 trait 对象，再取个短名字在通道里传递。

一个精妙的陷阱：while let vs loop

第 18 章学过 while let，很自然会想这样写 Worker：

1
2
3
while let Ok(job) = receiver.lock().unwrap().recv() {
    job();  // ⚠️ 锁还握着！
}

能编译、能运行，但并发性悄悄失效：Mutex 没有公有的 unlock 方法，锁的释放靠 lock 返回的 MutexGuard 被丢弃——而 while 条件表达式的值在整个循环体中都活着，job() 执行期间锁一直被持有，其他 Worker 全在干等。改成 loop + 循环体内的 let job = receiver.lock().unwrap().recv().unwrap();，MutexGuard 在这条 let 语句结束（job() 执行前）就被丢弃，锁立刻释放。一个变量的生命周期细节，决定了服务器是「假并发」还是真并发。

三、优雅停机：Drop、Terminate 与两段循环

ctrl-C 终止主线程时，所有 Worker 会被立刻掐断，哪怕正在处理请求——这不体面。真正的服务器要做到优雅停机（graceful shutdown）：处理完手头的活，再干净地退出。

第一步：实现 Drop。直觉写法是在 drop 里对每个 Worker 调用 thread.join()，但编译器报 E0507：我们手里只有 &mut Worker，而 join 要拿走所有权。解法正是第 17 章的模式——把字段类型改成 Option<thread::JoinHandle<()>>，清理时用 take() 把值移出来：

1
2
3
if let Some(thread) = worker.thread.take() {
    thread.join().unwrap();
}

第二步：让线程停下来。光 join 没用——Worker 还在 loop 里等任务，主线程会永远阻塞。于是通道不再只发任务，而是发一个枚举：enum Message { NewJob(Job), Terminate }。Worker 收到 NewJob 就干活，收到 Terminate 就 break 退出循环。

第三步：两段循环，避免死锁。Drop 里先向通道发 size 条 Terminate，再在另一个循环里逐个 join。为什么不能合成一个循环？书里的推演很精彩：假设只有两个 Worker，若边发终止消息边 join，第一个 Worker 正忙着处理请求时，Terminate 可能被第二个 Worker 抢走了——于是主线程永远等第一个 Worker 结束，而它永远等不到自己的终止消息。死锁。先全员广播、再统一收队，才保证每个线程都能收到自己的「下班通知」。

在 main 里用 listener.incoming().take(2) 只处理两个请求验证整套机制：第三个请求失败后打印 Shutting down.，随后是 Terminate 广播与逐个 worker 关闭的日志——服务器体面谢幕。

四、全书总结：这套项目浓缩了什么

实践建议：

1. while let 陷阱要刻进肌肉记忆：凡是用 MutexGuard，警惕它被 while 条件、临时变量拖着「多活」几行——锁的持有时间越短越好。
2. API 先行，实现随后：先写出期望的调用代码再动手实现，编译器的报错序列就是你的任务清单；通用逻辑（线程池）与业务（服务器）拆成独立 crate。
3. 优雅停机是生产素养：Drop 清理 + 显式退出信号是通配模式，不只是 Web 服务器专用——任何「长期运行的 worker 集合」都适用。

完结感言：从 cargo new 到一个能优雅停机的多线程 Web 服务器，21 篇笔记走完了《Rust 程序设计语言》全程。Rust 的学习曲线陡在前期——所有权、借用、生命周期在第一周就能劝退——但收益同样前置：一旦编译通过，运行时的心智负担骤降。书末作者说得好：你已经准备好实现自己的项目了，也别忘了社区里乐于助人的 Rustaceans。下一次遇到问题，去翻文档、读源码、提问吧——这门语言的下一个六年，有你一份。

想象你在一条没有路灯的山路上夜跑。JavaScript 的开发体验就是这样——你可以跑得飞快，但脚下的坑只有踩上去才知道。脚本跑起来、用户点下去、线上崩了，控制台甩给你一句 TypeError: xxx is not a function，这时你才知道：哦，这里传错了。

TypeScript 做的事，是在你出发前先派一架无人机把这条路照一遍。它不替你跑，也不改变路线，只是提前告诉你「第 3 公里有个坑」。官方 Handbook 对它的定义非常克制：TypeScript 是一个 JavaScript 程序的静态类型检查器（static typechecker）——在你代码运行之前（static）运行，确保程序里的类型是正确的一（typechecked）。

这一篇是系列的开场，我们要回答三个问题：这本 Handbook 讲了什么、类型到底是什么、以及 TypeScript 究竟能在运行前抓住哪些错误。

一、Handbook 的定位：指南，不是规范

Handbook 开篇就把边界说清楚了，这比急着学语法更重要：

读完之后你应该能做到三件事：读懂常见的 TypeScript 语法与模式、解释重要编译选项的作用、在大多数情况下正确预测类型系统的行为。

同时它明确列出了「非目标」（Non-Goals），很有意思：

• 不从头教 JavaScript 基础（函数、类、闭包）——需要时会给外链；
• 不是语言规范——为了可读性会跳过形式化描述和边角案例；
• 不讲与构建工具的集成（webpack、babel、react、vue……）——那些在别处。

也就是说，这是一本「几小时能读完」的务实指南，而不是一本字典。

二、类型是什么：从 message.toLowerCase() 说起

Handbook 的第一课不是语法，而是一个思想实验。看这段 JavaScript：

1
2
message.toLowerCase(); // 访问属性并调用
message();             // 直接调用

如果不知道 message 是什么值，没人能断言这两行的结果。它在运行时取决于四个问题：message 可调用吗？它有 toLowerCase 属性吗？该属性可调用吗？返回值又是什么？

1
2
3
const message = "Hello World!";
message.toLowerCase(); // 正常，返回 "hello world!"
message();             // TypeError: message is not a function

关键点在于：JavaScript 运行时是靠「值的类型」来决定行为的。对 string、number 这类原始类型，我们还能用 typeof 在运行时问一句；但对函数这种东西，运行时根本没有对应的机制来告诉你「这个参数需要有 flip 方法」：

1
2
3
function fn(x) {
  return x.flip();
}

这段代码读起来很清楚——x 必须是一个带 flip 方法的对象。但纯 JavaScript 里，唯一确认它能不能跑的办法就是真的去调用它。这就是动态类型：运行代码，然后看会发生什么。

TypeScript 给出的另一种选择是静态类型系统：在代码运行之前，就预测它应该做什么。把那句拗口的话翻译过来——类型，就是描述「哪些值可以传给 fn、哪些会崩」的一套语言。

三、静态类型检查：把 bug 挪到运行之前

为什么不早点发现？Handbook 给的理由很实在：就算你改完代码立刻重跑，也可能没测到那条分支；就算侥幸撞上了，中间可能已经堆了一大堆新代码，排查成本极高。

于是，const message = "hello!"; message(); 这段，TypeScript 在你保存文件的那一刻就报 This expression is not callable（错误码 2349）——代码还没跑，问题已经出现在编辑器里。

四、真正的杀手锏：非异常失败（Non-exception Failures）

这是本篇最值得记住的一节。前面讲的都是「运行时会抛错」的场景，但 JavaScript 里有大量不抛异常、却明显是 bug 的代码。ECMAScript 规范规定：调用不可调用的东西要抛错；但访问对象上不存在的属性，返回的是 undefined。

1
2
const user = { name: "Daniel", age: 26 };
user.location; // 不报错，返回 undefined

TypeScript 会明确报错：Property 'location' does not exist（2339）。它把「合法但可疑」的 JavaScript 也纳入了检查范围——这是一种取舍：牺牲一点表达自由度，换取大量真实 bug 被提前拦下。Handbook 举了三类典型：

第三类尤其惊艳：

1
2
3
4
5
6
const value = Math.random() < 0.5 ? "a" : "b";
if (value !== "a") {
  // ...
} else if (value === "b") {
  // Oops, unreachable
}

TypeScript 知道 value 的类型是 "a" | "b"，else 分支里它必然是 "a"，所以 value === "b" 永远不会成立——这种”死的分支”，纯靠肉眼 review 极容易漏掉。

五、类型不只是查错，还能让你少犯错

如果说查错是”事后拦截”，那 tooling 就是”事前预防”。类型检查器既然知道你正在操作的对象有哪些属性，它就能：

• 自动补全：输入 res.sen 时提示 send；
• 快速修复（quick fixes）：自动改正某些错误；
• 重构与导航：重命名、整理代码、跳转到定义、查找所有引用。

1
2
3
4
5
6
import express from "express";
const app = express();

app.get("/", function (req, res) {
  res.sen // ← 编辑器在这里就能提示 send / sendFile / sendStatus
});

这些能力全部构建在同一个类型检查器之上，而且跨平台——你常用的编辑器基本都有 TypeScript 支持。“类型”在这里从约束变成了生产力工具：它不只是告诉你哪里错了，还在你写的时候就把正确选项递到手边。

实践建议

1. 先建立心智模型，再记语法：把”类型 = 描述值能做什么”这句话刻在脑子里，后面学泛型、条件类型时都会轻松很多——它们只是把这句话参数化。
2. 优先解决”非异常失败”类报错：undefined 属性、拼错的方法名、忘加括号的函数调用，这三类是 TypeScript 性价比最高的收益点，迁移老项目时先盯它们。
3. 让编辑器替你干活：补全、跳转定义、查找引用、quick fix——这些不是”锦上添花”，而是你付了类型标注成本后应得的回报，值得花时间熟悉编辑器的 TS 快捷键。

小结

Handbook 的开篇没有急着教 string 和 number，而是先讲清 TypeScript 的立场：它是一个在代码运行前工作的静态检查器，目标是抓住”类型用错了”这一类最常见的 bug。它不仅能拦住会抛异常的错误，更能拦住那些 JavaScript 默许、但显然不对的写法（访问不存在的属性、拼错方法、函数忘了调用、不可达分支）；而它收集到的类型信息，又会立刻变成编辑器的补全与重构能力。

下一篇我们真正上手：tsc 编译器怎么用、类型注解写了之后去了哪（类型擦除）、模板字符串为什么被改写成 concat（降级编译），以及 strict、noImplicitAny、strictNullChecks 这三档”严格性旋钮”该怎么拧。

前十八章学的东西覆盖了 Rust 的绝大多数日常，但总有一些时刻，你会翻进「地下室」找工具：直接跟操作系统打交道、给 Vec 实现 Display、看懂别人代码里诡异的 <Dog as Animal>::baby_name()。本章就是这间地下室——书里也明说了，这些功能「很少会碰到」，但被设计成了一份遇到未知内容时的参考手册。

用攀岩打个比方：安全 Rust 是有护栏的栈道，99% 的风景都能到达；unsafe 则是撤掉护栏的岩壁——有些山（比如与 C 代码交互）根本没有栈道可走，你必须自己系好绳子。本章四大板块：不安全 Rust、高级 trait、高级类型、宏。先看地图：

一、不安全 Rust：手动挡模式

unsafe 不是「关闭安全检查」，这个澄清很重要：借用检查器照常工作，引用照常被检查。它只是额外解锁了五种编译器无法验证内存安全的操作：

裸指针有个容易忽略的细节：创建裸指针不需要 unsafe，解引用才需要。let r1 = &num as *const i32; 在安全代码里完全合法——创建指针本身无害，访问指向的值才可能出事。而且裸指针允许同一地址同时存在 *const 和 *mut，这在引用世界里是借用规则禁止的，也就埋下了数据竞争的种子。

本章最漂亮的例子是 split_at_mut：把一个 slice 从中间切成两半，各返回一个可变 slice。纯安全 Rust 写不出来（E0499：编译器只看到「同一个 slice 被可变借用两次」，理解不了「两个不重叠的区间」），但加上裸指针和 unsafe 块就能实现——而函数签名不带 unsafe，调用者毫无感知。这就是「不安全代码的安全抽象」：unsafe 块保持尽可能小，风险被封装在 Reviewed 过的内部。

另一个高频场景是 FFI（外部函数接口），让 Rust 直接调 C 标准库：

1
2
3
4
5
6
7
8
9
extern "C" {
    fn abs(input: i32) -> i32;
}

fn main() {
    unsafe {
        println!("Absolute value of -3 according to C: {}", abs(-3));
    }
}

extern 块里声明的函数永远是不安全的——其他语言不遵守 Rust 的规则，安全责任全在调用者身上。反过来，#[no_mangle] pub extern "C" fn 也能把 Rust 函数暴露给 C（这种 extern 不需要 unsafe）。

二、高级 trait：看懂标准库的进阶签名

关联类型 vs 泛型

Iterator trait 的定义用了一个占位类型：

1
2
3
4
5
pub trait Iterator {
    type Item;

    fn next(&mut self) -> Option<Self::Item>;
}

为什么不直接写 pub trait Iterator<T>？区别在于：用泛型的话，同一个 Counter 可以实现 Iterator<u32>、Iterator<String> 等多个版本，每次调用 next 都得加类型标注来消歧义；用关联类型则一个类型只能实现一次，Item 选定 u32 后就定死，调用时无需任何标注。一句话总结：泛型是「每次使用时选类型」，关联类型是「实现时选一次」。

默认泛型参数与运算符重载

Add trait 的定义是 trait Add<RHS=Self>——RHS=Self 就是默认类型参数，不指定时右操作数就是自身。想实现 Millimeters + Meters？impl Add<Meters> for Millimeters 显式覆盖默认值，单位换算在 add 方法里完成。这个设计还有个妙用：给现有 trait 加新的类型参数时提供默认值，可以不破坏任何已有实现地扩展 trait。

完全限定语法

两个 trait 有同名方法，类型自己也有同名方法时，person.fly() 默认调用类型直接实现的方法；想调 trait 的用 Pilot::fly(&person)。但遇到没有 self 参数的关联函数，得动用终极形态：

1
<Dog as Animal>::baby_name()  // 明确指定：Dog 的 Animal 实现里的 baby_name

通式是 <Type as Trait>::function(receiver_if_method, next_arg, ...)。平时用不上，报 E0283: type annotations required 时它就是解药。

父 trait 与 newtype 模式

trait OutlinePrint: fmt::Display 声明「实现我之前必须先实现 Display」，于是 trait 方法内可以自由使用 self.to_string()。没实现 Display 就直接实现 OutlinePrint？E0277 拦下。

newtype 模式（用元组结构体包一层）则绕过孤儿规则——Display 和 Vec 都不归你管，但 struct Wrapper(Vec<String>) 归你管，给 Wrapper 实现 Display 即可，且零运行时开销（封装在编译期就被省略）。想透传内部类型的所有方法就实现 Deref，想收敛行为就手写需要的几个方法。

三、高级类型：!、别名与动态大小

类型别名：同义词不是新类型

type Kilometers = i32; 里的 Kilometers 只是 i32 的另一个名字，可以互相加、可以传给收 i32 的函数——和 Millimeters 那种独立新类型完全不同（后者能拦住单位混用）。别名的主战场是消除重复：

1
2
3
type Thunk = Box<dyn Fn() + Send + 'static>;  // 一长串类型一个名字搞定

type Result<T> = std::result::Result<T, std::io::Error>;  // std::io 就这么干

std::io::Result<T> 让 Write trait 里满屏的 Result<..., Error> 变成 Result<usize>，且不损失 ? 等语法支持——因为它本质还是那个 Result。

never type：从不返回的 !

! 是一个没有任何值的类型，用于「发散函数」：fn bar() -> ! 表示 bar 永不返回。它最有意思的用法藏在 continue 里：

1
2
3
4
let guess: u32 = match guess.trim().parse() {
    Ok(num) => num,
    Err(_) => continue,  // 一个分支 u32，一个分支 continue，为什么能编译？
};

因为 continue 的值就是 !，而 ! 可以强转为任何类型——Err 分支实际不会产生值（控制权交回循环），Rust 于是推断整个 match 是 u32。panic!（如 Option::unwrap 的 None 分支）和无限 loop 也都是 !。

动态大小类型（DST）

str（不是 &str！）是一个 DST——长度运行时才确定，所以根本没法创建 str 类型的变量。解决办法你天天在用：把 DST 放到指针后面。&str 实际是「地址 + 长度」两个值，编译期大小恒为 usize 的两倍。这条黄金规则还解释了 trait 对象为什么必须写成 &dyn Trait、Box<dyn Trait>：每个 trait 也是 DST。

配套的 Sized trait 会被隐式加到每个泛型参数上（fn generic<T>(t: T) 实为 fn generic<T: Sized>）；用 T: ?Sized（只能用于 Sized）可放宽，此时参数要改成 &T 这类指针形式。

四、高级函数与闭包

函数可以当参数传——类型是 fn（小写，函数指针），注意不是闭包 trait Fn：

1
2
3
4
5
fn do_twice(f: fn(i32) -> i32, arg: i32) -> i32 {
    f(arg) + f(arg)
}

do_twice(add_one, 5)  // 12

函数指针实现了全部三个闭包 trait，所以收闭包的函数也能收函数指针；反之，只收 fn 不收闭包的场景主要是与 C 代码交互——C 没有闭包。另外 map(ToString::to_string)、map(Status::Value)（元组结构体构造器也是函数指针！）这类写法之所以可行，靠的就是函数指针与完全限定语法。

返回闭包则不能直接写返回类型（闭包是 trait，大小未知），标准姿势是 trait 对象：

1
2
3
fn returns_closure() -> Box<dyn Fn(i32) -> i32> {
    Box::new(|x| x + 1)
}

五、宏：为写代码而写代码

宏 = 元编程，与函数的关键区别一张表看清：

声明宏 macro_rules! 本质是「对 Rust 代码做 match」——匹配的是代码结构而非值。vec! 的简化版一窥究竟：

1
2
3
4
5
6
7
8
9
10
#[macro_export]
macro_rules! vec {
    ( $( $x:expr ),* ) => {
        {
            let mut temp_vec = Vec::new();
            $( temp_vec.push($x); )*
            temp_vec
        }
    };
}

$x:expr 捕获任意表达式，$()* 按匹配次数重复生成代码。vec![1, 2, 3] 展开后就是三行 push。

过程宏更像函数：吃进 TokenStream（token 序列），吐出 TokenStream，必须放在独立的 proc-macro = true crate 里。三种形态：

derive 宏的标准流水线：syn 把 TokenStream 解析成语法树（拿到 ast.ident 即结构体名）→ quote! 用模板（#name 占位符）生成 impl HelloMacro for #name 代码 → into() 转回 TokenStream 交给编译器。#[derive(HelloMacro)] struct Pancakes; 就能自动打印 Hello, Macro! My name is Pancakes!——这正是 Rust 没有反射却能做到「运行时打印类型名」的方式。

六、实践建议与总结

1. unsafe 的三条纪律：块保持尽可能小；优先封装成安全 API 对外暴露；可变静态变量能不用就不用，用第16章的并发原语替代。
2. 区分「新类型」和「别名」：要类型安全拦住单位混用，用 newtype；只为少打字，用 type 别名。
3. 见到看不懂的签名别慌：T: ?Sized、Add<RHS=Self>、<Dog as Animal>::fn、-> Box<dyn Fn> 都出自本章——把它当参考手册，下次在报错信息或他人代码里碰到，回来翻即可。

总结：本章把 Rust 的「地下室」逛了一遍——unsafe 撤掉护栏换取与硬件和 C 交互的能力；关联类型、默认泛型参数、完全限定语法、父 trait 和 newtype 模式撑起了标准库的进阶签名；! 与 DST 揭示了类型系统的两个隐藏角落；宏则让 Rust 拥有了编译期生成代码的元编程能力。下一章是最后一站：把全书所学倾注到一个多线程 Web 服务器项目里。

先看一行你写过不下百次的代码：

1
let x = 5;

问你这里用了什么语法特性？「变量绑定」，对吧。但书里揭了个底：x 本身就是一个模式。let 语句的完整形态其实是 let PATTERN = EXPRESSION;——变量名只是「形式最朴素的模式」，它的含义是「把任何值绑定到变量 x，不管值是什么」。

这就像收快递：快递单上的收件格式（模式）和实际包裹（值）对上了，你就能「拆开取件」——把里面的东西一件件拿出来用。Rust 里拆这个「包裹」的动作无处不在，match、if let、for、let、甚至函数参数，全都是同一个机制的不同入口。本章就把「包裹拆解说明书」完整过一遍：模式能用在哪、什么模式必须百发百中、以及九种模式语法的正确用法。

一、模式的六个使用位置

你已经在不经意间用过很多模式了。先来一张全局地图：

两个容易忽略的位置：

let 解构元组。let (x, y, z) = (1, 2, 3); 会把 1、2、3 分别绑定到三个变量。但元素数量必须严格对上，否则直接编译错误：

1
2
3
let (x, y) = (1, 2, 3);
// error[E0308]: mismatched types
// expected a tuple with 3 elements, found one with 2 elements

while let 弹栈是它最经典的用武之地——stack.pop() 返回 Option，取到 Some 就循环，取到 None 就自然停止：

1
2
3
4
5
6
7
8
let mut stack = Vec::new();
stack.push(1);
stack.push(2);
stack.push(3);

while let Some(top) = stack.pop() {
    println!("{}", top); // 依次打印 3、2、1
}

函数参数也能是模式，这是最少人知道的一个：

1
2
3
fn print_coordinates(&(x, y): &(i32, i32)) {
    println!("Current location: ({}, {})", x, y);
}

值 &(3, 5) 匹配模式 &(x, y)，x 得到 3，y 得到 5。闭包参数同理。

二、可反驳性：模式会不会「失手」

注意上面表格里反复出现的一对词。模式分两种：

• 不可反驳（irrefutable）：能匹配任何传进来的值，永远不会失败。let x = 5; 里的 x 就是——任何值它都接得住。
• 可反驳（refutable）：对某些可能的值会匹配失败。if let Some(x) = a_value 里的 Some(x) 就是——如果 a_value 是 None，匹配就失败了。

这条区分决定了各位置「选人标准」，也是新手最常撞上的编译错误来源：

两个方向的反例都值得看一眼。在 let 里用可反驳模式：

1
2
let Some(x) = some_option_value;
// error[E0005]: refutable pattern in local binding: `None` not covered

编译器的态度很明确：万一进来的是 None，这行代码没法有意义地继续，所以不放行。修复方式是改用 if let，给代码一个「匹配不上就跳过」的出路。

反过来，在 if let 里用不可反驳模式也不行——它会警告（不是报错）irrefutable if-let pattern：一个永远匹配的条件写在 if let 里毫无意义，不如直接写 let。

三、模式语法工具箱

基础四式：字面量、命名变量、或、范围

1
2
3
4
5
match x {
    1 | 2 => println!("one or two"),   // | 表示「或」
    1..=5 => println!("one through five"), // 闭区间范围，比 1|2|3|4|5 省事得多
    _ => println!("anything"),
}

范围 ..= 只允许用于数字和 char，因为只有这两种类型编译器能在编译期判断范围是否为空。

命名变量的「遮蔽」陷阱

这是本章最值得多看两眼的地方。猜猜下面的代码打印什么？

1
2
3
4
5
6
7
8
9
let x = Some(5);
let y = 10;

match x {
    Some(50) => println!("Got 50"),
    Some(y) => println!("Matched, y = {:?}", y),
    _ => println!("Default case, x = {:?}", x),
}
println!("at the end: x = {:?}, y = {:?}", x, y);

答案是 Matched, y = 5——不是 10。match 会开启新作用域，第二个分支的 Some(y) 引入了一个新的变量 y（遮蔽外部那个 10），它匹配任何 Some 里的值，于是绑定了 x 里的 5。循环结束后，外部的 y 依然是 10。

如果你的本意是「比较 Some 里的值和外部 y 是否相等」，答案是匹配守卫（后面讲到）：把模式改名为 Some(n)，再写 Some(n) if n == y。

解构：拆结构体、枚举和嵌套

解构结构体时，变量名不必与字段名一致（let Point { x: a, y: b } = p;），但更常用的是字段简写 let Point { x, y } = p;。还可以把字面量混进模式，用来「测一部分、绑另一部分」：

1
2
3
4
5
match p {
    Point { x, y: 0 } => println!("On the x axis at {}", x),
    Point { x: 0, y } => println!("On the y axis at {}", y),
    Point { x, y } => println!("On neither axis: ({}, {})", x, y),
}

解构枚举的模式必须对应枚举定义数据的方式：无数据的 Quit 只能匹配字面量；类结构体成员 Move { x, y } 像结构体；类元组成员 Write(text)、ChangeColor(r, g, b) 像元组。而且嵌套随便拆：

1
2
3
4
5
match msg {
    Message::ChangeColor(Color::Rgb(r, g, b)) => { /* ... */ }
    Message::ChangeColor(Color::Hsv(h, s, v)) => { /* ... */ }
    _ => ()
}

两个枚举的嵌套，一个模式里一次拆穿。结构体和元组还能再混搭：let ((feet, inches), Point {x, y}) = ((3, 10), Point { x: 3, y: -10 });。

忽略值的四种姿势

_ 和 _x 的区别很微妙但重要：

1
2
3
4
5
6
7
let s = Some(String::from("Hello!"));

if let Some(_s) = s { println!("found a string"); }
println!("{:?}", s); // 错误！s 已被移动进 _s

if let Some(_) = s { println!("found a string"); }
println!("{:?}", s); // 正常。_ 不绑定值，s 没有被移动

.. 的使用必须无歧义，(first, .., last) 合法，但 (.., second, ..) 会报错 `..` can only be used once per tuple or tuple struct pattern——编译器无法确定 second 到底是哪个位置。

匹配守卫：给模式追加 if 条件

模式表达不了「Some 里的值小于 5」这种条件，匹配守卫可以：

1
2
3
4
5
6
7
let num = Some(4);

match num {
    Some(x) if x < 5 => println!("less than five: {}", x),
    Some(x) => println!("{}", x),
    None => (),
}

守卫的条件可以使用模式中创建的变量（甚至外部的变量），这也是修复上面遮蔽陷阱的标准姿势：Some(n) if n == y 里的 y 是外部的 y，因为 if n == y 不是模式、不引入新变量。

一个优先级细节：4 | 5 | 6 if y 的语义是 (4 | 5 | 6) if y——守卫作用于整个「或」组合，而不只是最后一个 6。

@ 绑定：一边测试一边抓住

最后一件法宝。想测「id 在 3 到 7 之间」，又想在分支里用上这个值？@ 运算符两件事一起干：

1
2
3
4
5
6
7
8
9
10
11
match msg {
    Message::Hello { id: id_variable @ 3..=7 } => {
        println!("Found an id in range: {}", id_variable)
    }
    Message::Hello { id: 10..=12 } => {
        println!("Found an id in another range") // 测了范围但拿不到值
    }
    Message::Hello { id } => {
        println!("Found some other id: {}", id) // 拿得到值但没测范围
    }
}

id_variable @ 3..=7 = 「测试它在这个范围 + 把它存进变量」。中间分支只测不存，最后分支只存不测——@ 让你两个都要。

四、实践建议与总结

1. 记住「选人标准」：let/for/函数参数要百发百中（不可反驳），if let/while let 专为「可能失手」而生。看到 E0005 报错，第一反应是「这该用 if let 而不是 let」。
2. 警惕 match 里的变量遮蔽：分支模式里的名字是新变量，不是外部同名变量。想比较外部值，用匹配守卫 Some(n) if n == y。
3. 忽略值想清楚要不要「接住」：_ 不绑定不移动所有权，_x 会真的把值拿走。碰到所有权被意外移走的编译错误，检查是不是用了 _x。

总结：模式是 Rust 中区分数据形状的通用语法，match 靠它实现穷尽性检查，let 和函数参数靠它实现优雅解构。九种语法——字面量、命名变量、|、..=、解构、_/_x/..、匹配守卫、@ 绑定——组合起来能写出既简洁又安全的分派逻辑。下一章我们进入「高级特征」：unsafe、trait 高阶玩法等特定场景武器。

对应书源：《Rust 程序设计语言》第 17 章「Rust 的面向对象特性」

开篇：「Rust 到底算不算面向对象语言？」

番茄是水果还是蔬菜？植物学说它是水果，厨房里说它是蔬菜——答案取决于你采用哪套标准。「Rust 是不是面向对象」也是同一类问题，编程社区至今没有统一定义，在某些定义下 Rust 是，在另一些定义下不是。

所以本章不急着下结论，而是把大家普遍认可的面向对象特征拆成三块——对象、封装、继承——逐一对照 Rust 的实际做法。接着再动手实现一个经典设计模式（状态模式），最后讨论一个关键问题：照搬面向对象模式，是不是发挥了 Rust 的全部优势？

一、对象包含数据和行为：这一条 Rust 达标

《设计模式》（GoF，”四人帮”）对面向对象编程的定义是：

面向对象的程序由对象组成。一个对象包含数据和操作这些数据的过程，这些过程通常被称为方法或操作。

按这个标准，Rust 完全达标：struct 和 enum 装数据，impl 块提供方法。唯一的差别在于，Rust 刻意不把结构体和枚举叫作「对象」，以便和其他语言里的对象概念区分开。功能上，它们提供的是同一件事。

二、封装：pub 就是那道门

封装的意思是：对象的实现细节对使用它的代码不可见，唯一交互方式是公有 API。这样重构内部时不必改动外部代码。

Rust 的做法你已经熟悉——默认私有，用 pub 逐项开放。书里给了个漂亮的例子 AveragedCollection，它维护一个整型列表与列表平均值，并把平均值缓存下来：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
pub struct AveragedCollection {
    list: Vec<i32>,
    average: f64,
}

impl AveragedCollection {
    pub fn add(&mut self, value: i32) {
        self.list.push(value);
        self.update_average();
    }

    pub fn remove(&mut self) -> Option<i32> {
        let result = self.list.pop();
        match result {
            Some(value) => {
                self.update_average();
                Some(value)
            }
            None => None,
        }
    }

    pub fn average(&self) -> f64 {
        self.average
    }

    fn update_average(&mut self) {
        let total: i32 = self.list.iter().sum();
        self.average = total as f64 / self.list.len() as f64;
    }
}

结构体本身是 pub，但 list 和 average 字段仍是私有的。这一点至关重要：外部代码无法直接增删 list，因此「平均值与列表不同步」这种 bug 在结构上就不可能发生。而好处随之而来——将来想把 Vec<i32> 换成 HashSet<i32>，只要 add/remove/average 的签名不变，调用方一行都不用改；反之如果把 list 设为 pub，外部直接操作它，换数据结构就会引发连锁修改。

三、继承：Rust 明确没有，但给了两条替代路径

如果「必须有继承才算面向对象」，那 Rust 就不算。你无法定义一个结构体继承另一个结构体的字段和方法。但人们用继承通常出于两个原因，Rust 各有对应方案：

近年来继承在很多语言里「失宠」，因为它常常强迫子类共享并不需要的父类特性，设计变僵硬，还可能出现「子类调用了其实不适用于它的方法」。有些语言还只允许单继承，进一步限制了灵活性。出于这些原因，Rust 选了另一条路：用 trait 对象实现多态。

四、trait 对象：让不同类型的值共处一个集合

第 8 章说过，Vec 只能存同种元素，用 SpreadsheetCell 枚举可以绕开——但那要求类型集合在编译期就固定。如果写库的人无法预知使用者会新增什么类型呢？

设想一个 GUI 库：它遍历组件列表，对每个组件调用 draw。库作者知道 Button、TextField，但使用者可能想加 Image、SelectBox。做法是定义一个 Draw trait，让 Screen 持有 trait 对象的 vector：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
pub trait Draw {
    fn draw(&self);
}

pub struct Screen {
    pub components: Vec<Box<dyn Draw>>,
}

impl Screen {
    pub fn run(&self) {
        for component in self.components.iter() {
            component.draw();
        }
    }
}

Box<dyn Draw> 就是 trait 对象：它是「任何实现了 Draw 的类型」的替身。使用者只需为自己的类型实现 Draw，就能塞进 Screen：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
use gui::{Screen, Button};

fn main() {
    let screen = Screen {
        components: vec![
            Box::new(SelectBox {
                width: 75,
                height: 10,
                options: vec![
                    String::from("Yes"),
                    String::from("Maybe"),
                    String::from("No"),
                ],
            }),
            Box::new(Button {
                width: 50,
                height: 10,
                label: String::from("OK"),
            }),
        ],
    };

    screen.run();
}

如果换成泛型写法 Screen<T: Draw>，components 就只能是清一色 Button 或清一色 TextField。两种写法该怎么选？

run 不需要知道组件到底是 Button 还是 SelectBox，只关心「能调用 draw」——这很像动态类型语言里的鸭子类型（走起来像鸭子、叫起来像鸭子，那它就是鸭子）。区别在于：动态语言要到运行时才发现「这个对象没有 draw 方法」，而 Rust 在编译期就拦下，比如往 Screen 里塞一个 String，会直接报 error[E0277]: the trait bound 'String: Draw' is not satisfied。

代价是动态分发：编译器不知道 trait 对象的具体类型，只能在运行时查方法表，因此无法内联优化。

还有一条硬规则：只有对象安全的 trait 才能做成 trait 对象。实践中最常遇到的是——方法不能返回 Self、不能带泛型参数。因为 trait 对象已经「忘记」了具体类型。典型反例是 Clone（fn clone(&self) -> Self），写 Vec<Box<dyn Clone>> 会报 error[E0038]: the trait 'Clone' cannot be made into an object。

五、状态模式实战：一篇博客的发布工作流

状态模式的要点是：一个值有内部状态，行为随状态而变；每个状态各自负责自己的行为以及何时转移到下一个状态；持有状态的值对这些细节毫不知情。

需求是这样的：新建的博文是草案 → 请求审核 → 审核通过 → 发布。其他一切非法操作（比如在审核前直接发布）都不产生效果。用状态模式实现时，Post 内部持有一个 trait 对象：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
pub struct Post {
    state: Option<Box<dyn State>>,
    content: String,
}

impl Post {
    pub fn new() -> Post {
        Post {
            state: Some(Box::new(Draft {})),
            content: String::new(),
        }
    }

    pub fn request_review(&mut self) {
        if let Some(s) = self.state.take() {
            self.state = Some(s.request_review())
        }
    }

    pub fn approve(&mut self) {
        if let Some(s) = self.state.take() {
            self.state = Some(s.approve())
        }
    }

    pub fn content(&self) -> &str {
        self.state.as_ref().unwrap().content(self)
    }
}

trait State {
    fn request_review(self: Box<Self>) -> Box<dyn State>;
    fn approve(self: Box<Self>) -> Box<dyn State>;
    fn content<'a>(&self, post: &'a Post) -> &'a str {
        ""
    }
}

几个设计细节值得单独拎出来：

三个状态各自实现转移规则：Draft::request_review 返回 PendingReview，PendingReview::approve 返回 Published，而 Draft::approve 和 Published::* 都返回 self（非法操作静默无效）。于是「未审核的博文不能显示内容」这条规则，全部集中在状态对象里，Post 自身一无所知。

权衡取舍：优点显而易见——要看「已发布博文有哪些行为」，只需看 Published 一处；新增状态只需加一个 struct 并为其实现 trait，不用到处改 match。缺点也有三个：状态之间互相耦合（想在 PendingReview 和 Published 之间插入 Scheduled，就得改 PendingReview 的代码）；存在重复逻辑（想给返回 self 的方法加默认实现会破坏对象安全）；Post 里 request_review/approve 的模板化代码，方法多了可以考虑用宏消除。

六、更好的一种可能：把状态编码进类型

既然目标是「非法状态不可达」，那不如让类型系统直接拦住它。换个思路：Post::new() 返回的不是 Post 而是 DraftPost，而 DraftPost 根本没有 content 方法：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
pub struct Post {
    content: String,
}

pub struct DraftPost {
    content: String,
}

impl Post {
    pub fn new() -> DraftPost {
        DraftPost { content: String::new() }
    }

    pub fn content(&self) -> &str {
        &self.content
    }
}

impl DraftPost {
    pub fn add_text(&mut self, text: &str) {
        self.content.push_str(text);
    }

    pub fn request_review(self) -> PendingReviewPost {
        PendingReviewPost { content: self.content }
    }
}

pub struct PendingReviewPost {
    content: String,
}

impl PendingReviewPost {
    pub fn approve(self) -> Post {
        Post { content: self.content }
    }
}

request_review 和 approve 都获取 self 的所有权，消费掉旧实例、返回新类型。于是「拿到能读 content 的 Post」的唯一路径，就是 DraftPost → request_review → PendingReviewPost → approve → Post。想显示草案内容？那行代码压根编译不过。调用方相应要重新绑定变量：

1
2
3
4
5
let mut post = Post::new();
post.add_text("I ate a salad for lunch today");
let post = post.request_review();
let post = post.approve();
assert_eq!("I ate a salad for lunch today", post.content());

实践建议

1. 同质用泛型，异质用 trait 对象。集合元素类型一致且编译期已知，就用泛型 + trait bound 享受静态分发；需要让使用者自行扩展类型集合，再用 Box<dyn Trait>，并坦然接受动态分发的那点开销。
2. 让非法状态无法被表示。能用类型系统在编译期拦住的 bug，就不要留到运行时去「返回空字符串」。这是 Rust 相比传统 OOP 的额外红利。
3. 别生搬设计模式。Rust 拥有所有权、trait、泛型这些面向对象语言没有的武器，照搬 OOP 模式未必是最优解——先问一句「这个约束能不能交给编译器」。

小结

trait 对象是 Rust 获取部分面向对象能力的手段：用少量运行时性能换取灵活性，进而支撑状态模式这类可维护性模式。但同时，Rust 也提供了「把状态编码进类型」这种更彻底的方案——它不是面向对象模式，却能把 bug 挡在部署之前。这正是本章的落点：面向对象模式在 Rust 中始终可用，但并不总是最佳选择。

下一篇进入第 18 章「模式和匹配」，那些散落全书的 match、if let，终于要被系统地讲一次了。

对应书源：《Rust 程序设计语言》第 16 章「无畏并发」

开篇：并发编程的「噩梦」与 Rust 的解法

多线程编程是许多开发者的噩梦。在 C/C++ 中，一个数据竞争（data race）可能潜伏数月，直到某个特定时机才 crash；在 Java 里，虽然内存模型定义了 happen-before 规则，但死锁和活锁依然防不胜防。调试这些 bug 就像在黑暗中捉迷藏——你知道它在那里，但永远不确定何时会撞上。

Rust 对这个问题给出了一个激进的答案：把并发错误变成编译错误。通过所有权和类型系统，Rust 在编译期就拒绝那些有数据竞争风险的代码。这不是魔法，而是把第 4 章的所有权规则、第 15 章的智能指针，一并延伸到了多线程场景。官方给这个特性起了个响亮的名字——无畏并发（fearless concurrency）。

一、线程基础：spawn、join 与 move 闭包

1.1 创建线程与等待结束

Rust 标准库提供 1:1 线程模型（一个语言线程对应一个 OS 线程），通过 thread::spawn 创建：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
use std::thread;
use std::time::Duration;

let handle = thread::spawn(|| {
    for i in 1..10 {
        println!("hi number {} from the spawned thread!", i);
        thread::sleep(Duration::from_millis(1));
    }
});

// 主线程继续执行自己的代码
for i in 1..5 {
    println!("hi number {} from the main thread!", i);
}

// 阻塞等待子线程结束
handle.join().unwrap();

spawn 返回一个 JoinHandle，调用其 join 方法会阻塞当前线程直到子线程结束。join 放的位置很关键：放在主线程的 for 循环之前，子线程会先跑完；放在之后，两者交替执行。

1.2 move 闭包：把所有权「搬」进线程

如果闭包要捕获主线程的数据，默认借用可能不安全——Rust 不知道子线程会运行多久。此时需要 move 关键字强制转移所有权：

1
2
3
4
5
let v = vec![1, 2, 3];

let handle = thread::spawn(move || {
    println!("Here's a vector: {:?}", v);
});

不加 move 时编译器报错 E0373：closure may outlive borrowed value。加了 move 后，v 的所有权归子线程所有，主线程不能再使用它——所有权规则在线程间依然生效。

二、消息传递：不要共享内存，要通过通讯共享内存

Go 语言的口号「不要通过共享内存来通讯；而是通过通讯来共享内存」在 Rust 中也有完美实现——通道（channel）。

2.1 mpsc 通道的基本用法

1
2
3
4
5
6
7
8
9
10
11
12
use std::sync::mpsc;
use std::thread;

let (tx, rx) = mpsc::channel(); // multiple producer, single consumer

thread::spawn(move || {
    let val = String::from("hi");
    tx.send(val).unwrap(); // send 获取所有权并转移给接收端
});

let received = rx.recv().unwrap(); // 阻塞直到收到值
println!("Got: {}", received);

mpsc::channel() 返回发送端 tx 和接收端 rx。关键点：send 会拿走值的所有权，发送后发送方不能再使用该值，否则报 E0382 use of moved value。

2.2 接收端的两种方式

2.3 多生产者：克隆发送端

mpsc 允许多个发送端，通过 clone 实现：

1
2
3
4
5
6
7
let tx1 = tx.clone();
thread::spawn(move || { tx1.send(...).unwrap(); });
thread::spawn(move || { tx.send(...).unwrap(); });

for received in rx { // rx 可作为迭代器，通道关闭时结束
    println!("Got: {}", received);
}

多个线程并发发送，接收端按到达顺序处理。输出顺序每次可能不同，这是并发的本质特性。

三、共享状态：Mutex + Arc

通道类似单所有权，而共享内存需要多所有权。Rust 的方案是 互斥器（mutex）。

3.1 Mutex：获取锁才能访问

1
2
3
4
5
6
7
use std::sync::Mutex;

let m = Mutex::new(5);
{
    let mut num = m.lock().unwrap(); // 获取锁，阻塞直到成功
    *num = 6; // num 是 MutexGuard，解引用后可变访问内部值
} // 离开作用域自动释放锁（Drop 实现）

Mutex<T> 是一个智能指针：lock() 返回 MutexGuard，它实现了 Deref 指向内部数据，并在离开作用域时自动释放锁。类型系统保证不获取锁就无法访问内部数据。

3.2 多线程共享：Rc 不行，Arc 才行

直觉上，用 Rc<T> 包一层 Mutex<T> 就可以多线程共享了：

1
2
3
4
let counter = Rc::new(Mutex::new(0));
// ...
let counter = Rc::clone(&counter);
let handle = thread::spawn(move || { ... });

但编译报错：Rc<Mutex<i32>> cannot be sent between threads safely。原因是 Rc<T> 的引用计数不是线程安全的，多个线程同时增减计数会数据竞争。

解决方案是 Arc<T>（atomically reference counted），API 与 Rc<T> 相同，但计数操作是原子的：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
use std::sync::{Mutex, Arc};

let counter = Arc::new(Mutex::new(0));
let mut handles = vec![];

for _ in 0..10 {
    let counter = Arc::clone(&counter);
    let handle = thread::spawn(move || {
        let mut num = counter.lock().unwrap();
        *num += 1;
    });
    handles.push(handle);
}

for h in handles { h.join().unwrap(); }
println!("Result: {}", *counter.lock().unwrap()); // 10

3.3 死锁的提醒

Rust 的类型系统能防止数据竞争，但无法阻止逻辑层面的死锁。如果线程 A 持有锁 X 等待锁 Y，同时线程 B 持有锁 Y 等待锁 X，就会永远阻塞。规避策略与其他语言相同：统一加锁顺序、使用超时等。

四、Send 与 Sync：并发的「类型护照」

Rust 并发模型的精髓在于两个标记 trait：

• Send：类型可以安全地转移所有权到另一个线程。几乎所有类型都是 Send，除了 Rc<T>（引用计数非原子）和裸指针。
• Sync：类型可以安全地被多个线程同时引用（即 &T 是 Send）。Mutex<T> 是 Sync 的，RefCell<T> 和 Cell<T> 不是（运行时借用检查非线程安全）。

自动推导规则：完全由 Send/Sync 类型组成的类型，自动也是 Send/Sync。几乎不需要手动实现——手动实现需要 unsafe 代码。

thread::spawn 的签名中要求闭包实现 Send，这就是为什么 Rc<T> 无法直接传给 spawn。编译器在类型层面「发护照」：没 Send「签证」的就不能过境到别的线程。

五、实践建议

1. 优先用消息传递，次选共享状态：通道让数据所有权流向清晰；共享状态只在性能必要或已有架构需要时才考虑。
2. 共享状态就用 Arc<Mutex<T>>：这是 Rust 多线程可变共享的标准配方，别试图用 Rc<T> 绕过——编译器不答应。
3. 锁的粒度尽量小：把 lock() 调用和后续操作限制在最小的作用域内，减少竞争窗口。别让锁跨过 await 或阻塞调用。

六、总结

Rust 的并发不是通过增加运行时复杂度来换取安全，而是把第 4 章的所有权、第 15 章的智能指针，自然延伸到了多线程。你写的并发代码一旦通过编译，就从根本上排除了数据竞争和悬垂引用——这正是「无畏」二字的含义。

下一篇将进入第 17 章，聊聊 Rust 的面向对象特性——trait 与面向对象设计模式的碰撞。

前几章我们反复看到 Rust 用所有权和借用规则在编译期杜绝内存问题：一个值只有一个所有者，引用要么多个不可变、要么一个可变。这些规则在绝大多数情况下非常清晰。但当数据结构本身需要”多个入口共享同一块内存”，或者”不可变外壳里藏着可变内核”时，编译器的严格有时会成为表达能力的障碍。智能指针就是 Rust 提供的标准答案：它们仍然遵守安全规则，只是把检查的场合从”编译时”挪到了”运行时”，或者通过额外的元数据（引用计数）扩展了所有权的语义。

开篇：引用只是「借」，智能指针是「拥有」

第4章的引用 &T 只借用数据，没有任何额外开销。智能指针则是一类拥有它们指向的数据，并附带额外元数据或功能的数据结构。String 和 Vec<T> 其实也算智能指针——它们拥有数据、管理容量、保证 UTF-8 或内存连续性。

标准库中最常用的三个是 Box<T>、Rc<T> 和 RefCell<T>，而理解它们的关键在于两个 trait：

• Deref：让智能指针可以像引用一样用 * 解引用
• Drop：让智能指针在离开作用域时自动执行清理代码

一、Box：把数据放到堆上

Box<T> 是最简单的智能指针，功能只有两个：在堆上分配数据，以及留在栈上的指针。没有额外开销。

1
2
let b = Box::new(5);
println!("b = {}", b);  // 像访问栈数据一样自然

Box<T> 真正的价值在于递归类型。Rust 需要在编译时知道类型大小，而递归类型理论上可以无限嵌套，大小未知。cons list（Lisp 风格链表）是典型的例子：

1
2
3
4
5
// 编译错误：recursive type `List` has infinite size
enum List {
    Cons(i32, List),
    Nil,
}

把 List 换成 Box<List>，问题就解决了——Box 是指针，大小固定（平台指针宽度），编译器能算出 Cons 需要 i32 + box 指针 的空间，递归链被打破：

1
2
3
4
5
6
7
8
9
enum List {
    Cons(i32, Box<List>),
    Nil,
}

let list = Cons(1,
    Box::new(Cons(2,
        Box::new(Cons(3,
            Box::new(Nil))))));

虽然函数式语言常用 cons list，Rust 里 Vec<T> 是更好的选择。这里用它只是因为概念简单，能清晰展示递归类型与 Box 的关系。

二、Deref trait：让自定义类型也能用 *

Box<T> 能像引用一样用 *y 解引用，是因为它实现了 Deref trait。我们自己也可以做到。

实现 Deref 只需要提供一个 deref 方法，返回内部数据的引用：

1
2
3
4
5
6
7
8
9
10
use std::ops::Deref;

struct MyBox<T>(T);

impl<T> Deref for MyBox<T> {
    type Target = T;
    fn deref(&self) -> &T {
        &self.0
    }
}

当写下 *y 时，Rust 实际上执行的是 *(y.deref())。deref 返回引用而非值，是为了不转移所有权。

解引用强制转换（Deref Coercions）

这是 Deref 带来的更实用的功能。当函数参数类型是 &str 而传入 &MyBox<String> 时，Rust 会自动链式调用 deref：

1
2
3
fn hello(name: &str) { ... }
let m = MyBox::new(String::from("Rust"));
hello(&m);  // 自动：&MyBox<String> → &String → &str

没有强制转换，你得写 hello(&(*m)[..])。强制转换发生在编译期，零运行时开销。

注意反向不可能：不可变引用不能强转为可变引用，因为借用规则无法保证唯一性。

三、Drop trait：离开作用域时自动「收尾」

Drop trait 让你定义值离开作用域时要执行的清理逻辑。Box<T> 用它来释放堆内存，你也可以用来关闭文件或网络连接。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
struct CustomSmartPointer {
    data: String,
}

impl Drop for CustomSmartPointer {
    fn drop(&mut self) {
        println!("Dropping `{}`", self.data);
    }
}

fn main() {
    let c = CustomSmartPointer { data: String::from("my stuff") };
    let d = CustomSmartPointer { data: String::from("other stuff") };
    println!("Created.");
}
// 输出顺序：Created. → Dropping `other stuff` → Dropping `my stuff`

变量以创建顺序的相反顺序被丢弃，所以 d 先于 c。

提前丢弃：std::mem::drop

不能手动调用 c.drop()——Rust 禁止显式析构，因为结束时还会自动再调用一次，导致 double free。如果确实需要提前清理，用标准库的 std::mem::drop 函数（注意是小写 drop，不是 Drop trait 的方法）：

1
2
drop(c);  // prelude 已导入，提前释放
println!("CustomSmartPointer dropped before end of main.");

四、Rc：一个值，多个所有者

有些场景天然需要多所有权。比如图结构中多个边指向同一个节点，节点应该直到没有边指向它时才被释放。Rc<T>（reference counting）就是为此设计：

1
2
3
4
5
6
7
8
9
10
use std::rc::Rc;

enum List {
    Cons(i32, Rc<List>),
    Nil,
}

let a = Rc::new(Cons(5, Rc::new(Cons(10, Rc::new(Nil)))));
let b = Cons(3, Rc::clone(&a));
let c = Cons(4, Rc::clone(&a));

Rc::clone(&a) 不会深拷贝数据，只是把引用计数加 1。标准库故意让 Rc::clone 与深拷贝的 .clone() 同名但语义不同，这是 Rust 社区的习惯：看到 Rc::clone 就知道”只是增计数，不用担心性能”。

用 Rc::strong_count(&a) 可以观察计数变化：创建 a 时为 1，克隆给 b 后为 2，给 c 后为 3，c 离开作用域后自动减回 2。

⚠️ Rc<T> 只能用于单线程。多线程的引用计数在第16章讲。

五、RefCell：编译器信不过你，你自己来保证

Rc<T> 解决了多所有权，但它只提供不可变访问。如果要修改共享数据怎么办？RefCell<T> 引入内部可变性（interior mutability）：外表不可变，内部可变。

RefCell<T> 的借用规则不在编译期检查，而在运行时检查。违反规则不会编译错误，而是直接 panic：

1
2
3
4
5
6
use std::cell::RefCell;

let cell = RefCell::new(vec![1, 2, 3]);
cell.borrow_mut().push(4);     // 可变借用，OK
cell.borrow().len();           // 不可变借用，OK
// 同时两个 borrow_mut() → panic: already borrowed: BorrowMutError

borrow() 返回 Ref<T>，borrow_mut() 返回 RefMut<T>，两者都实现了 Deref，可以像普通引用一样用。RefCell 内部维护活跃借用的计数，规则与编译期完全一致：多个不可变 ✅，单个可变 ✅，多个可变 ❌，可变+不可变 ❌。

Mock 对象的经典用例

这是书里最有说服力的例子。假设有个 Messenger trait，方法签名要求 &self（不可变），但测试时 mock 对象需要记录调用过的消息（需要可变内部状态）：

1
2
3
4
5
6
7
8
9
struct MockMessenger {
    sent_messages: RefCell<Vec<String>>,
}

impl Messenger for MockMessenger {
    fn send(&self, message: &str) {
        self.sent_messages.borrow_mut().push(String::from(message));
    }
}

外部调用者看到的 send 接收 &self，符合 trait 契约；内部通过 RefCell 完成可变操作。运行时如果出了错（比如两个 borrow_mut 重叠），测试会 panic，而不是带着 bug 上线。

Rc<RefCell>：多所有者 + 可变

把两者嵌套，就能得到”多个所有者且都能修改”的数据结构：

1
2
3
4
5
let value = Rc::new(RefCell::new(5));
let a = Rc::new(Cons(Rc::clone(&value), Rc::new(Nil)));
let b = Cons(Rc::new(RefCell::new(6)), Rc::clone(&a));

*value.borrow_mut() += 10;  // a 和 b 共享的 5 变成 15

六、引用循环与 Weak：小心「互相指」带来的泄漏

Rust 不保证完全避免内存泄漏——如果 Rc<T> 之间形成循环引用，计数永远到不了 0，内存就不会释放：

1
2
3
4
5
6
7
let a = Rc::new(Cons(5, RefCell::new(Rc::new(Nil))));
let b = Rc::new(Cons(10, RefCell::new(Rc::clone(&a))));
// 让 a 指向 b，形成循环
if let Some(link) = a.tail() {
    *link.borrow_mut() = Rc::clone(&b);
}
// a 和 b 的 strong_count 都是 2，离开作用域后都剩 1，内存泄漏

解决方法是 Weak<T> 弱引用。Rc::downgrade 创建弱引用，它不拥有数据，只增加 weak_count。当 strong_count 降为 0 时，值就被释放，弱引用通过 upgrade() 返回 Option<Rc<T>> 来安全访问——如果值还在就返回 Some，已被释放就返回 None。

树结构的父节点引用是 Weak<T> 的典型场景：父节点拥有子节点（Rc 强引用），子节点知道父节点（Weak 弱引用）。父节点被丢弃时子节点跟着消失，子节点被丢弃时父节点不受影响。

1
2
3
4
5
struct Node {
    value: i32,
    parent: RefCell<Weak<Node>>,      // 弱引用，不拥有父节点
    children: RefCell<Vec<Rc<Node>>>, // 强引用，拥有子节点
}

实践建议

1. 默认用 Box<T> 处理堆分配和递归类型，它最简单、零开销、不会引入新的借用复杂度。
2. 需要共享读权限时选 Rc<T>，需要共享写权限时套 RefCell<T>，但记住：
   • Rc<T> 只读、RefCell<T> 单线程——两者都不是万能药
   • Rc<RefCell<T>> 组合给了灵活性，也给了制造引用循环的能力
3. 有父子双向引用时，子→父用 Weak<T>，这是避免循环泄漏的标准做法。始终问自己：这个方向的引用是”拥有”还是”知道”？拥有用 Rc，知道用 Weak。

智能指针的本质，是 Rust 在”编译期保证安全”这条主线上开出的几扇侧门：Box 解决大小未知，Rc 扩展所有权语义，RefCell 把检查推迟到运行时，Weak 打破循环。它们都封装在安全的 API 里，底线没有破——只是换了一种方式守住它。下一章，我们把这些工具带进并发世界，看看 Rust 如何用所有权系统实现”无畏并发”。

本系列基于官方《Rust 程序设计语言》（TRPL）逐章学习。前几章我们一直在写代码本身：所有权、测试、迭代器。这一章换个视角，把 Cargo 当作真正的工程工具来用——定制构建配置、写文档注释、把 crate 发布到 crates.io，以及用工作空间管理一组协同开发的包。一句话：从”我自己能跑”走向”别人能用、团队能一起维护”。

开篇：同一份代码，两副面孔

cargo build 和 cargo build --release 的输出你多半见过：

1
2
3
4
$ cargo build
    Finished dev [unoptimized + debuginfo] target(s) in 0.0 secs
$ cargo build --release
    Finished release [optimized] target(s) in 0.0 secs

方括号里的 unoptimized + debuginfo 与 optimized，就是两套发布配置（release profiles）的差异。它们不是”两个 Cargo”，而是同一条编译流水线的两组参数：调试时希望编译快、能打断点；发布时希望程序快、体积小，编译久一点无所谓。理解了这一点，本章几乎所有”发布相关”的设计就都好懂了——在不同阶段付出不同的代价。

一、发布配置：把编译参数写进 Cargo.toml

Cargo 有 dev 与 release 两个主要配置，分别对应 cargo build 与 cargo build --release。项目里没有 [profile.*] 时全部用默认值；一旦写上，只覆盖你写的那部分：

1
2
3
4
5
[profile.dev]
opt-level = 0

[profile.release]
opt-level = 3

opt-level 取 0~3，越高优化越多、编译越慢。开发期频繁编译，所以 dev 默认 0；发布只编译一次却要运行很多次，所以 release 默认 3。想在开发时多要一点性能，改成 1 即可——不必自己发明一套构建流程。

二、文档注释：写给”使用者”而非编译器

// 是给读源码的人看的，/// 则是文档注释（documentation comments）：支持 Markdown，由 rustdoc 渲染成 HTML，用来告诉别人如何使用你的 crate，而不是它如何被实现。

1
2
3
4
5
6
7
8
9
10
11
12
/// Adds one to the number given.
///
/// # Examples
///
/// ```
/// let arg = 5;
/// let answer = my_crate::add_one(arg);
/// assert_eq!(6, answer);
/// ```
pub fn add_one(x: i32) -> i32 {
    x + 1
}

运行 cargo doc 会在 target/doc 生成 HTML；cargo doc --open 直接构建并打开浏览器（连同所有依赖的文档）。

除了 # Examples，社区常用的小节还有三个，本质是一份”提醒你去检查”的清单：

文档注释最妙的一点是文档即测试：cargo test 会把文档里的示例代码当测试运行：

1
2
3
   Doc-tests my_crate
running 1 test
test src/lib.rs - add_one (line 5) ... ok

如果你改了函数却忘了改例子，assert_eq! 就会失败——文档从此不会”过期”。

三、//! 与 pub use：让使用者少走几步

/// 描述它之后的项；//! 描述包含它的项，因此常写在 src/lib.rs 或模块根部，为整个 crate 或模块写总览：

1
2
3
4
//! # My Crate
//!
//! `my_crate` is a collection of utilities to make performing certain
//! calculations more convenient.

它必须放在文件最顶部（”最后一行之后没有任何代码”恰恰说明它属于这个文件本身）。

pub use 解决另一个问题：你的文件结构往往不等于用户想要的 API 结构。假设 art 库把内容拆成 kinds 与 utils 两个模块，用户必须写：

1
2
use art::kinds::PrimaryColor;
use art::utils::mix;

作者只需在 lib.rs 顶部加三行重导出（re-export）：

1
2
3
pub use self::kinds::PrimaryColor;
pub use self::kinds::SecondaryColor;
pub use self::utils::mix;

用户就能写成 use art::PrimaryColor;。pub use 让内部组织与对外 API 解耦：内部维持清晰分层，对外提供扁平入口，cargo doc 首页也会直接列出这些重导出项。原有的深层路径依然可用，只是不再强迫用户走那么深。

四、发布到 crates.io：把代码交到别人手里

发布不是一条命令，而是一串有先后顺序的准备：

缺 description 或 license 时，cargo publish 会直接报 error: api errors: missing or empty metadata fields: description, license.。补齐后大致是这样：

1
2
3
4
5
6
7
[package]
name = "guessing_game"
version = "0.1.0"
authors = ["Your Name <you@example.com>"]
edition = "2018"
description = "A fun game where you guess what number the computer has chosen."
license = "MIT OR Apache-2.0"

license 用 SPDX 标识符；找不到合适的就用 license-file 指向许可证文件。许多 Rust 项目选择 MIT OR Apache-2.0 双许可（OR 分隔多个标识符）。

两条必须记住的规则：

• 发布是永久性的：版本号一旦发布，不能覆盖、不能删除代码。crates.io 要做”永久文档服务器”，好让所有依赖者的构建永远可复现；想改就升版本号（遵循语义化版本）再发布一次。
• cargo yank 只是撤回，不是删除：cargo yank --vers 1.0.1 让新项目不再选中该版本，但已有 Cargo.lock 的项目照旧能下载，不会被”断供”，加 --undo 可撤销撤回。它不是用来删除误传密钥的——那种情况请立刻重置密钥。

五、工作空间：让一组 crate 一起长大

项目变大时，”一个大库”往往该拆成几个协同的小 crate。Cargo 的工作空间（workspaces）正是为这种场景准备：一组共享同一个 Cargo.lock 和同一个 target 目录的包。

1
2
3
4
5
6
7
8
9
├── Cargo.toml      ← 只写 [workspace]，没有 [package]
├── Cargo.lock      ← 全工作空间唯一
├── add-one/        ← 库 crate
│   ├── Cargo.toml
│   └── src/lib.rs
├── adder/          ← 二进制 crate
│   ├── Cargo.toml
│   └── src/main.rs
└── target/         ← 全工作空间唯一

根 Cargo.toml 只负责登记成员：

1
2
3
4
5
6
[workspace]

members = [
    "adder",
    "add-one",
]

adder 要用 add-one，需显式声明路径依赖（Cargo 不假定工作空间内的 crate 互相依赖）：

1
2
[dependencies]
add-one = { path = "../add-one" }

一个容易踩的坑是外部依赖：假设 add-one 在 Cargo.toml 里加了 rand = "0.5.5"，根目录 Cargo.lock 会记录它；但若 adder 也写 use rand;，编译就会报错——rand 并未成为 adder 的依赖。Cargo 不做”依赖传染”：每个 crate 想用什么，都要在自己的 Cargo.toml 里声明。好在声明之后不会下载第二份拷贝，所有成员共享同一版本。测试同理：根目录 cargo test 跑遍所有成员，cargo test -p add-one 只跑指定 crate。

共享 target 与 Cargo.lock 是最实际的两个收益：既省磁盘、省编译时间，也从根上消除了”同一依赖装了两个版本”的不兼容麻烦。

六、装别人的工具、扩展自己的能力

cargo install 用来在本地安装二进制 crate（只有含 src/main.rs 这类二进制目标的包能装），比如第 12 章提到的 ripgrep：

1
2
$ cargo install ripgrep
  Installing ~/.cargo/bin/rg

它装到 Rust 根目录的 bin（rustup 默认是 $HOME/.cargo/bin），把这个目录放进 $PATH 就能直接用。其定位是”方便 Rust 开发者安装社区工具”，而非替代系统包管理器。

Cargo 还能被扩展：只要 $PATH 里有名为 cargo-something 的可执行文件，就能用 cargo something 调用它，甚至会被 cargo --list 列出。于是”安装第三方 cargo 子命令”的体验与内建命令几乎一致。

实践建议与总结

1. 配置是分阶段的：dev/release 的差异提醒我们，开发期优先反馈速度、发布期优先运行质量；opt-level 是唯一常见的手调旋钮，别急着全局优化。
2. 文档要写成”可执行的承诺”：/// + # Examples 让 cargo test 替你检查示例是否过期，//! 给出 crate 总览，pub use 把好用的入口顶到台前——三者合起来才是”别人能用”的文档。
3. 先想清楚公开边界再发布：名称唯一、版本永久、依赖锁版本是硬约束；发布前补齐 description/license，出事后记住 yank 是”止损”而非”删除”。

回到开头那句：Cargo 的进阶功能几乎都在回答同一个问题——这份代码要交给别人（或未来的自己）吗？ 要交给别人，就该有文档、有明确的公开 API、有可复现的依赖与版本。下一章我们重新回到语言本身，看 Box<T>、Rc<T>、RefCell<T> 这些”智能指针”如何在编译期规则之外，为数据所有权提供更多可能。

本系列基于官方《Rust 程序设计语言》（TRPL）逐章学习。前面我们一直在”写得对”的层面打磨：所有权、生命周期、测试。这一章转向”写得巧”——Rust 从函数式语言借来的两大件：闭包和迭代器。它们让代码看起来更高级，却几乎不付运行时性能代价。这一章还顺手把上一章的 minigrep 用迭代器重写了一遍，作为”抽象到底值不值”的实证。

开篇：一个健身 App 的两难

设想你在一个生成定制健身计划的初创公司，后端用 Rust 写。核心算法要考虑年龄、BMI、喜好、近期活动量……计算一次大约两秒，所以我们用一个 simulated_expensive_calculation 函数模拟它（打印 calculating slowly...、睡 2 秒、返回传入的数字）。

业务逻辑 generate_workout(intensity, random_number) 是：低强度（intensity < 25）建议做俯卧撑和仰卧起坐；高强度时随机数为 3 就休息，否则跑步若干分钟。慢计算因此被调用三处——第一个 if 分支调了两次（用户白等一倍），else 内的 if 分支不该调，最后再调一次。

第一次重构是把结果提取到变量 expensive_result：调用统一了，代价却是所有情况都得先等两秒，包括不需要结果的分支。我们要的是——在一处定义代码，只在需要时才执行。这正是闭包登场的地方：像把菜谱写进信封揣兜里，写下来不算做菜，饿了拆开照做，且只做一次。

闭包：能捕获环境的匿名函数

闭包是”可存进变量、或作为参数传给其他函数的匿名函数”。语法从一对竖线开始：|num| { ... }，多参数用逗号分隔，只有一行时大括号可省，体最后一行即返回值。这条 let 存的是定义而非调用结果——代码躺在变量里，等你用 expensive_closure(intensity) 触发。

类型推断与标注

闭包不要求标注参数与返回类型：它存在变量里、匿名、不供库用户调用，且通常很短、上下文很窄，编译器能可靠推断，强制标注只会重复编译器已知的信息。想写也行，四种等价写法：

1
2
3
4
fn  add_one_v1   (x: u32) -> u32 { x + 1 }
let add_one_v2 = |x: u32| -> u32 { x + 1 };
let add_one_v3 = |x|             { x + 1 };
let add_one_v4 = |x|               x + 1  ;

代价是：闭包的具体类型会被第一次调用锁定。下面这段先传 String 再传整数，编译器会报 E0308: mismatched types，因为 x 与返回值已被推断并锁定为 String：

1
2
3
let example_closure = |x| x;
let s = example_closure(String::from("hello"));
let n = example_closure(5);   // error[E0308]: expected String, found integer

用 Fn trait 把闭包装进结构体

要解决”同一结果被算两次”，除了到处存变量，还有更优雅的方案：用一个结构体存放闭包并缓存结果——这个模式叫 memoization 或惰性求值（lazy evaluation）。难点在于结构体字段必须有类型，而每个闭包实例都有自己独有的匿名类型（即使签名相同也互不相同），所以要用泛型 + trait bound。标准库提供的三个 Fn 系列 trait 中，这里用 Fn：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
struct Cacher<T>
where
    T: Fn(u32) -> u32,
{
    calculation: T,
    value: Option<u32>,
}

impl<T> Cacher<T>
where
    T: Fn(u32) -> u32,
{
    fn new(calculation: T) -> Cacher<T> {
        Cacher { calculation, value: None }
    }

    fn value(&mut self, arg: u32) -> u32 {
        match self.value {
            Some(v) => v,
            None => {
                let v = (self.calculation)(arg);
                self.value = Some(v);
                v
            }
        }
    }
}

字段私有，是为了让 Cacher 自己管理缓存而不被外部乱改。调用方把闭包交给 Cacher::new，之后一律走 value(intensity)：有缓存直接返回，没有才执行并存入。于是慢计算最多只跑一次，generate_workout 得以专注业务逻辑。（顺带一提：函数也实现了这三个 Fn trait，不需要捕获环境时直接传函数即可。）

但这个 Cacher 有两个限制，导致难以复用：

捕获环境与三种 Fn trait

闭包还有一个函数没有的能力：捕获其定义作用域中的变量。

1
2
let x = 4;
let equal_to_x = |z| z == x;   // 闭包体内用了 x，尽管 x 不是参数

写成 fn equal_to_x(z: i32) -> bool { z == x } 会编译失败：E0434: can't capture dynamic environment in a fn item。代价是闭包要为捕获的变量占内存，函数则从不需要。捕获方式恰好对应函数取参的三种方式：

equal_to_x 只读取 x，因此实现 Fn。若在参数列表前加 move 关键字，就强制闭包取得环境值的所有权——这在把闭包传给新线程时最实用（第 16 章详讲）。演示一下 move 的后果，这次用 Vec 而非整数（整数可拷贝、不会真的移走）：

1
2
3
let x = vec![1, 2, 3];
let equal_to_x = move |z| z == x;
println!("can't use x here: {:?}", x);   // error[E0382]: use of moved value: `x`

x 被移进闭包，main 里就不能再用它了。实用建议：trait bound 先从 Fn 开始，编译器会告诉你何时该换成 FnMut 或 FnOnce。

迭代器：惰性的传送带

迭代器负责”遍历每一项 + 决定何时结束”，最大特点是惰性：let v1_iter = v1.iter(); 本身什么都不发生，直到被真正消费。核心是标准库的 Iterator trait：

1
2
3
4
5
pub trait Iterator {
    type Item;
    fn next(&mut self) -> Option<Self::Item>;
    // 此处省略了方法的默认实现
}

type Item 是关联类型（第 19 章详解），即迭代器产出元素的类型；next 是唯一必须实现的方法，一次返回一个项包在 Some 里，结束返回 None。直接调用 next 时迭代器变量必须 mut——它会改变记录位置的状态，也就是消费了迭代器（for 循环会自己取得所有权并内部处理可变性）。三个常用入口方法：

消费适配器 vs 迭代器适配器

Iterator trait 的众多方法分两类，区别十分关键：

经典陷阱是只写 v1.iter().map(|x| x + 1); 而不消费它——编译器会警告 unused std::iter::Map ... iterator adaptors are lazy and do nothing unless consumed，那个闭包从未被调用过。补上 collect 才是完整用法：

1
2
let v2: Vec<_> = v1.iter().map(|x| x + 1).collect();
assert_eq!(v2, vec![2, 3, 4]);

filter 则常与捕获环境的闭包搭配——下面这个函数只挑出指定尺码的鞋子，闭包捕获了 shoe_size：

1
2
3
4
5
fn shoes_in_my_size(shoes: Vec<Shoe>, shoe_size: u32) -> Vec<Shoe> {
    shoes.into_iter()
        .filter(|s| s.size == shoe_size)
        .collect()
}

因为 map 接受闭包，我们可以自定义”每个元素要做什么”，同时复用 Iterator 提供的迭代逻辑——这是闭包与迭代器配合的绝佳示例。

自定义迭代器：只需要实现 next

只要为类型实现 Iterator，就能免费获得标准库所有默认方法。下面这个 Counter 从 1 数到 5：

1
2
3
4
5
6
7
8
9
10
11
12
impl Iterator for Counter {
    type Item = u32;

    fn next(&mut self) -> Option<Self::Item> {
        self.count += 1;
        if self.count < 6 {
            Some(self.count)
        } else {
            None
        }
    }
}

有了 next，所有默认方法就都免费到手了。例如把两个 Counter 配对（第二个 skip(1) 跳过首值）、相乘、只留能被 3 整除者、再求和：

1
2
3
4
5
6
let sum: u32 = Counter::new()
    .zip(Counter::new().skip(1))
    .map(|(a, b)| a * b)
    .filter(|x| x % 3 == 0)
    .sum();
assert_eq!(18, sum);

注意 zip 只产生四对值：理论上第五对 (5, None) 从未产生，因为 zip 在任一输入迭代器返回 None 时就返回 None。

回头重写 minigrep：用迭代器去掉 clone 和可变状态

上一章我们留下两处”以后再说”的地方，现在可以收拾了。

一、Config::new：从索引 + clone 到移动所有权

原来 new 接收 &[String]，自身不拥有参数，为了返回拥有 query/filename 的 Config，只好 clone 两次。既然 env::args 本身就返回迭代器，我们干脆把迭代器的所有权交给 Config::new：

1
2
3
4
5
// main.rs：不再 collect 成 Vec，直接传迭代器
let config = Config::new(env::args()).unwrap_or_else(|err| {
    eprintln!("Problem parsing arguments: {}", err);
    process::exit(1);
});

签名相应改成 pub fn new(mut args: std::env::Args) -> Result<Config, &'static str>（args 要被迭代推进状态，故需 mut），函数体里的长度检查与索引访问全部换成 next：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
impl Config {
    pub fn new(mut args: std::env::Args) -> Result<Config, &'static str> {
        args.next();                    // 第一个值是程序名，跳过

        let query = match args.next() {
            Some(arg) => arg,
            None => return Err("Didn't get a query string"),
        };
        let filename = match args.next() {
            Some(arg) => arg,
            None => return Err("Didn't get a file name"),
        };

        let case_sensitive = env::var("CASE_INSENSITIVE").is_err();
        Ok(Config { query, filename, case_sensitive })
    }
}

每次 next() 返回 Some 就 match 取出 String，返回 None 说明参数不够，直接 Err 提前返回。因为迭代器把值交给我们，String 是移动进 Config 的——不再需要 clone 分配新内存。

二、search：用适配器替代可变 vector

原版 search 里有个 let mut results = Vec::new(); 加上 for/push。用 filter + collect 之后，整个函数的意图变成一句话：

1
2
3
4
5
pub fn search<'a>(query: &str, contents: &'a str) -> Vec<&'a str> {
    contents.lines()
        .filter(|line| line.contains(query))
        .collect()
}

函数式风格倾向于最小化可变状态，这会让未来的并行搜索更易实现。多数 Rust 开发者更偏好迭代器版本：初看略绕，习惯后反而更易看清代码目的——样板循环被抽走，只剩业务特有的过滤条件。

性能对比：循环一定更快吗？

直觉上更”底层”的 for 循环应更快。用《福尔摩斯探案集》全文查找 “the” 做基准测试：

迭代器版本还略快一点。这正是 Rust 的零成本抽象（zero-cost abstractions）：抽象不引入运行时开销，与本贾尼·斯特劳斯特卢普在《Foundations of C++》中提出的零开销原则一致——”你不需要的，无需为其买单；你需要时，也找不到更好的代码了”。

书中还有一段音频解码器代码：用 coefficients.iter().zip(&buffer[i - 12..i]).map(...).sum::<i64>() 做线性预测。其汇编与手写版相同——迭代次数固定为 12，Rust 直接展开（unroll）循环，系数放进寄存器，也没有数组边界检查。放心用迭代器和闭包：它们让代码更高级，却不因此变慢。

实践建议与总结

1. 闭包用于”延迟执行 + 捕获上下文”：要把行为存起来稍后执行、或让它记住几个外部变量时用它；一旦想复用”缓存结果”逻辑，就升级为 Cacher 式结构体（注意单值缓存、类型写死两个限制）。
2. Fn/FnMut/FnOnce 先别背：从 Fn 写起，让编译器告诉你是否需要更强的约束；需要把值搬进新线程时再考虑 move。
3. 优先迭代器风格，但先想清楚消费点：漏掉 collect/sum 这类消费适配器，整条链式调用等于没写（编译器会警告）；iter/iter_mut/into_iter 决定你拿到的是引用还是所有权，这直接决定要不要 clone。

本章两个”意外收获”更值钱：一是抽象不必然付费——filter().collect() 与手写循环打平甚至更快；二是抽象收益会累积——上一章的 clone 与可变 results 能被干净消掉，正因它们被隔离在 Config::new 和 search 两个小函数里。下一章走出代码：cargo 的 profile 定制、文档注释与发布 crate。