fix: fix some word

Author: thinkgos

src/chapter-02.md

@@ -43,7 +43,7 @@ struct Foo {
 
 对于下一个字段`small`, 对齐方式很简单: 它是一个1字节的值, 在结构中当前字节偏移量是1+3+4=8. 这已经是字节对齐的, 所以`small`可以紧随`normal`字段. 但对于`long`, 我们又遇到了一个问题. 我们现在是1+3+4+1=9字节进入`Foo`. 如果`Foo`是对齐的, 那么`long`就不是我们想要的8字节对齐, 所以我们必须再插入7字节的填充来使`long`再次对齐. 这也方便了我们确保最后一个字段`short`所需的 2 字节对齐, 使总数达到26字节. 现在我们已经完成了所有字段的对齐, 我们还需要确定`Foo`本身的对齐方式. 这里的规则是使用 `Foo` 任何一个字段的最大对齐方式, 由于`long`的原因, 它将是8字节. 因此, 为了确保`Foo`在放入数组时保持对齐, 编译器添加了最后6个字节的填充, 使 `Foo` 的大小是其32字节对齐的倍数.
 
-现在我们准备摆脱`C`语言的束缚, 考虑一下如果我们不使用清单2-1中的 `repr(C)`, 布局会发生什么变化. `C`表示法的主要限制之一是它要求我们以原始结构定义中的相同顺序放置所有字段. 默认的`Rust`表示法`repr(Rust)`除去了这一限制, 以及其他一些较小的限制, 例如对恰好有相同字段的类型进行确定性的字段排序. 也就是说, 在使用默认的`Rust`布局时, 即使两个不同的类型以相同的顺序共享相同类型的所有字段、, 也不能保证它们的布局是一样的.
+现在我们准备摆脱`C`语言的束缚, 考虑一下如果我们不使用清单2-1中的 `repr(C)`, 布局会发生什么变化. `C`表示法的主要限制之一是它要求我们以原始结构定义中的相同顺序放置所有字段. 默认的`Rust`表示法`repr(Rust)`除去了这一限制, 以及其他一些较小的限制, 例如对恰好有相同字段的类型进行确定性的字段排序. 也就是说, 在使用默认的`Rust`布局时, 即使两个不同的类型以相同的顺序共享相同类型的所有字段, 也不能保证它们的布局是一样的.
 
 由于我们现在可以对字段进行重新排序, 我们可以按照大小递减的顺序排列段. 这意味着我们不再需要`Foo`字段之间的填充; 字段本身被用来实现必要的对齐！`Foo` 的大小与字段大小相当: 只有16个字节. 这就是为什么`Rust`默认情况下不对一个类型在内存中的布局做太多保证的原因之一: 通过给编译器更多重新排列的余地, 我们可以产生更有效的代码.
 

src/chapter-03.md

@@ -2,11 +2,11 @@
 
 每个项目, 无论大小, 都有一个`API`. 事实上, 它通常有几个. 其中有些是面向用户的, 比如`HTTP`端点或命令行接口, 有些是面向开发者, 比如库的开放接口. 除此之外, `Rust` `crate`还有一些内部接口: 每个类型、`trait`和模块边界都有自己的微型`API`, 你的代码与之交互. 随着你的代码库的规模和复杂性的增长, 你会发现非常值得在如何设计内部`API`上投入一些心思和精力, 使用和维护代码尽可能的愉快.
 
-在这一章中, 我们将探讨在`Rust`中编写惯用接口的一些最重要的考虑事项, 无论这些接口的用户是你自己还是使用你的库的其他开发者. 这基本上可以归结为四个原则: 你的接口应该是不出意料的(`unsurprising`), 灵活的(`flexible`), 明显的(`obvious`)和受约束的(`constrained`). 我将依次讨论这些原则, 为编写可靠、可用的接口提供一些指导.
+在这一章中, 我们将探讨在`Rust`中编写惯用接口的一些最重要的考虑事项, 无论这些接口的用户是你自己还是使用你的库的其他开发者. 这基本上可以归结为四个原则: 你的接口应该是不出意外的(`unsurprising`), 灵活的(`flexible`), 明显的(`obvious`)和受约束的(`constrained`). 我将依次讨论这些原则, 为编写可靠、可用的接口提供一些指导.
 
 我强烈建议读完本章后, 看看``Rust`API`指南(`https://rust-lang.github.io/api-guidelines/`). 那里有一个很好的清单, 根据清单中详细介绍了解每项建议. 本章中的许多建议也可以通过`cargo clippy`工具检查的, 如果你还没有使用该工具, 建议开始在代码中使用它. 我还鼓励你阅读`RFC 1105`(`https://rust-lang.github.io/rfcs/1105-api-evolution.html`)和`The Cargo Book`中关于`SemVer`兼容性的章节(`https://doc.rust-lang.org/cargo/reference/semver.html`), 这些章节涵盖了`Rust`中哪些是、哪些不是破坏性变更.
 
-## 意料中的(Unsurprising)
+## 不意外的(Unsurprising)
 
 最小意外原则, 又称最小意外法则, 在软件工程中经常被提及, 同样也适用于`Rust`接口. 尽可能地, 你的接口应该足够直观, 应该直观到如果用户需要推断, 他们通常会推断正确. 当然, 并不是所有关于你的应用程序的接口能直观呈现, 但任何不令人意外的东西都应该是直观的. 核心思想是紧贴用户可能已经了解的东西, 这样他们就不必以不同于他们习惯的方式重新学习概念. 这样一来, 你就可以把他们的脑力节省下来, 用于解决那些真正与你的接口有关的问题.
 
@@ -18,7 +18,7 @@
 
 由此推论, 名字相同的东西实际上应该以同样的方式工作. 否则, 例如, 如果你的`iter`方法使用`self`, 或者`SomethingError`类型没有实现`Error`, 用户很可能会根据他们期望的接口工作方式写出错误的代码. 他们会感到意外和沮丧, 并不得不花时间去研究你的接口与他们的期望有何不同. 如果我们能为用户省去这种麻烦, 我们就应该这么做.
 
-### 类型的共同 traits
+### 类型的共同traits
 
 `Rust`中的用户还会做出一个主要的假设, 即接口中的一切都"都能正常工作". 他们期望能够用`{:?}`打印任何类型, 并将任何东西发送到另一个线程, 他们还期望每个类型都是`Clone`. 在可能的情况下, 我们应该再次避免让用户感到意外, 并积极实现大多数标准`trait`, 即使我们并不立即需要它们.