Update: unified format

contents/advance/circle-self-ref/circle-reference.md

@@ -91,13 +91,13 @@ thread 'main' has overflowed its stack
 fatal runtime error: stack overflow
 ```
 
-通过 `a.tail` 的调用，Rust 试图打印出 `a -> b ->a···` 的所有内容，但是在不懈的努力后，`main` 线程终于不堪重负，发生了[栈溢出](https://course.rs/pitfalls/stack-overflow.html)。
+通过 `a.tail` 的调用，Rust 试图打印出 `a -> b -> a ···` 的所有内容，但是在不懈的努力后，`main` 线程终于不堪重负，发生了[栈溢出](https://course.rs/pitfalls/stack-overflow.html)。
 
 以上的代码可能并不会造成什么大的问题，但是在一个更加复杂的程序中，类似的问题可能会造成你的程序不断地分配内存、泄漏内存，最终程序会不幸**OOM**，当然这其中的 CPU 损耗也不可小觑。
 
-总之，创建引用并不简单，但是也并不是完全遇不到，当你使用`RefCell<Rc<T>>`或者类似的类型嵌套组合(具备内部可变性和引用计数)时，就要打起万分精神，前面可能是深渊！
+总之，创建引用并不简单，但是也并不是完全遇不到，当你使用 `RefCell<Rc<T>>` 或者类似的类型嵌套组合（具备内部可变性和引用计数）时，就要打起万分精神，前面可能是深渊！
 
-那么问题来了？ 如果我们确实需要实现上面的功能，该怎么办？答案是使用`Weak`。
+那么问题来了？ 如果我们确实需要实现上面的功能，该怎么办？答案是使用 `Weak`。
 
 ## Weak
 `Weak` 非常类似于 `Rc`，但是与 `Rc` 持有所有权不同，`Weak` 不持有所有权，它仅仅保存一份指向数据的弱引用：如果你想要访问数据，需要通过 `Weak` 指针的 `upgrade` 方法实现，该方法返回一个类型为 `Option<Rc<T>>` 的值。
@@ -112,26 +112,26 @@ fatal runtime error: stack overflow
 | `Weak` | `Rc`         |
 |--------|-------------|
 | 不计数            | 引用计数        |
-|   不拥有所有权      | 拥有值的所有权 |
-| 不阻止值被释放(drop) | 所有权计数归零，才能drop | 
-| 引用的值存在返回Some,不存在返回None | 引用的值必定存在 | 
-| 通过`upgrade`取到`Option<Rc<T>>`,然后再取值 | 通过`Deref`自动解引用，取值无需任何操作 |
+| 不拥有所有权      | 拥有值的所有权 |
+| 不阻止值被释放(drop) | 所有权计数归零，才能 drop |
+| 引用的值存在返回 `Some`，不存在返回 `None ` | 引用的值必定存在 |
+| 通过 `upgrade` 取到 `Option<Rc<T>>`，然后再取值 | 通过 `Deref` 自动解引用，取值无需任何操作 |
 
-通过这个对比，可以非常清晰的看出`Weak`为何这么弱，而这种弱恰恰非常适合我们实现以下的场景：
+通过这个对比，可以非常清晰的看出 `Weak` 为何这么弱，而这种弱恰恰非常适合我们实现以下的场景：
 
-- 持有一个`Rc`对象的临时引用，并且不在乎引用的值是否依然存在
-- 阻止`Rc`导致的循环引用，因为`Rc`的所有权机制，会导致多个`Rc`都无法计数归零
+- 持有一个 `Rc` 对象的临时引用，并且不在乎引用的值是否依然存在
+- 阻止 `Rc` 导致的循环引用，因为 `Rc` 的所有权机制，会导致多个 `Rc` 都无法计数归零
 
-使用方式简单总结下：**对于父子引用关系，可以让父节点通过`Rc`来引用子节点，然后让子节点通过`Weak`来引用父节点**。
+使用方式简单总结下：**对于父子引用关系，可以让父节点通过 `Rc` 来引用子节点，然后让子节点通过 `Weak` 来引用父节点**。
 
-#### Weak总结
-因为Weak本身并不是很好理解，因此我们再来帮大家梳理总结下，然后再通过一个例子，来彻底掌握。
+#### Weak 总结
+因为 `Weak` 本身并不是很好理解，因此我们再来帮大家梳理总结下，然后再通过一个例子，来彻底掌握。
 
-`Weak`通过`use std::rc::Weak`来引入，它具有以下特点:
+`Weak` 通过 `use std::rc::Weak` 来引入，它具有以下特点:
 
 - 可访问，但没有所有权，不增加引用计数，因此不会影响被引用值的释放回收
-- 可由`Rc<T>`调用`downgrade`方法转换成`Weak<T>`
-- `Weak<T>`可使用`upgrade`方法转换成`Option<Rc<T>>`,如果资源已经被释放，则`Option`的值是`None`
+- 可由 `Rc<T>` 调用 `downgrade` 方法转换成 `Weak<T>`
+- `Weak<T>` 可使用 `upgrade` 方法转换成 `Option<Rc<T>>`，如果资源已经被释放，则 `Option` 的值是 `None`
 - 常用于解决循环引用的问题
 
 一个简单的例子：
@@ -157,13 +157,13 @@ fn main() {
 }
 ```
 
-需要承认的是，使用`Weak`让Rust本来就堪忧的代码可读性又下降了不少，但是。。。真香，因为可以解决循环引用了。
+需要承认的是，使用 `Weak` 让 Rust 本来就堪忧的代码可读性又下降了不少，但是。。。真香，因为可以解决循环引用了。
 
-## 使用Weak解决循环引用
+## 使用 Weak 解决循环引用
 理论知识已经足够，现在用两个例子来模拟下真实场景下可能会遇到的循环引用。
 
 #### 工具间的故事
-工具间里，每个工具都有其主人，且多个工具可以拥有一个主人；同时一个主人也可以拥有多个工具，在这种场景下，就很容易形成循环引用，好在我们有`Weak`: 
+工具间里，每个工具都有其主人，且多个工具可以拥有一个主人；同时一个主人也可以拥有多个工具，在这种场景下，就很容易形成循环引用，好在我们有 `Weak`：
 ```rust
 use std::rc::Rc;
 use std::rc::Weak;
@@ -182,8 +182,8 @@ struct Gadget {
 }
 
 fn main() {
-    // 创建一个Owner
-    // 需要注意，该Owner也拥有多个`gadgets`
+    // 创建一个 Owner
+    // 需要注意，该 Owner 也拥有多个 `gadgets`
     let gadget_owner : Rc<Owner> = Rc::new(
         Owner {
             name: "Gadget Man".to_string(),
@@ -191,35 +191,35 @@ fn main() {
         }
     );
 
-    // 创建工具，同时与主人进行关联：创建两个gadget，他们分别持有gadget_owner 的一个引用。
+    // 创建工具，同时与主人进行关联：创建两个 gadget，他们分别持有 gadget_owner 的一个引用。
     let gadget1 = Rc::new(Gadget{id: 1, owner: gadget_owner.clone()});
     let gadget2 = Rc::new(Gadget{id: 2, owner: gadget_owner.clone()});
 
     // 为主人更新它所拥有的工具
-    // 因为之前使用了`Rc`，现在必须要使用`Weak`，否则就会循环引用
+    // 因为之前使用了 `Rc`，现在必须要使用 `Weak`，否则就会循环引用
     gadget_owner.gadgets.borrow_mut().push(Rc::downgrade(&gadget1));
     gadget_owner.gadgets.borrow_mut().push(Rc::downgrade(&gadget2));
 
-    // 遍历 gadget_owner的gadgets字段
+    // 遍历 gadget_owner 的 gadgets 字段
     for gadget_opt in gadget_owner.gadgets.borrow().iter() {
 
         // gadget_opt 是一个 Weak<Gadget> 。 因为 weak 指针不能保证他所引用的对象
         // 仍然存在。所以我们需要显式的调用 upgrade() 来通过其返回值(Option<_>)来判
         // 断其所指向的对象是否存在。
-        // 当然，Option为None的时候这个引用原对象就不存在了。
+        // 当然，Option 为 None 的时候这个引用原对象就不存在了。
         let gadget = gadget_opt.upgrade().unwrap();
         println!("Gadget {} owned by {}", gadget.id, gadget.owner.name);
     }
 
-    // 在main函数的最后， gadget_owner, gadget1和daget2都被销毁。
+    // 在 main 函数的最后，gadget_owner，gadget1 和 daget2 都被销毁。
     // 具体是，因为这几个结构体之间没有了强引用（`Rc<T>`），所以，当他们销毁的时候。
-    // 首先 gadget1和gadget2被销毁。
-    // 然后因为gadget_owner的引用数量为0，所以这个对象可以被销毁了。
+    // 首先 gadget1 和 gadget2 被销毁。
+    // 然后因为 gadget_owner 的引用数量为 0，所以这个对象可以被销毁了。
     // 循环引用问题也就避免了
 }
 ```
 
-#### tree数据结构
+#### tree 数据结构
 ```rust
 use std::cell::RefCell;
 use std::rc::{Rc, Weak};
@@ -276,18 +276,18 @@ fn main() {
 
 ```
 
-这个例子就留给读者自己解读和分析，我们就不画蛇添足了：）
+这个例子就留给读者自己解读和分析，我们就不画蛇添足了:）
 
-## unsafe解决循环引用
-除了使用Rust标准库提供的这些类型，你还可以使用`unsafe`里的原生指针来解决这些棘手的问题，但是由于我们还没有讲解`unsafe`，因此这里就不进行展开，只附上[源码链接](https://codes.rs/unsafe/self-ref.html), 挺长的，需要耐心o_O
+## unsafe 解决循环引用
+除了使用 Rust 标准库提供的这些类型，你还可以使用 `unsafe` 里的原生指针来解决这些棘手的问题，但是由于我们还没有讲解 `unsafe`，因此这里就不进行展开，只附上[源码链接](https://codes.rs/unsafe/self-ref.html), 挺长的，需要耐心o_o
 
-虽然`unsafe`不安全，但是在各种库的代码中依然很常见用它来实现自引用结构，主要优点如下:
+虽然 `unsafe` 不安全，但是在各种库的代码中依然很常见用它来实现自引用结构，主要优点如下:
 
 - 性能高，毕竟直接用原生指针操作
-- 代码更简单更符合直觉: 对比下`Option<Rc<RefCell<Node>>>`
+- 代码更简单更符合直觉: 对比下 `Option<Rc<RefCell<Node>>>`
 
 
 ## 总结
-本文深入讲解了何为循环引用以及如何使用`Weak`来解决，同时还结合`Rc`、`RefCell`、`Weak`等实现了两个有实战价值的例子，让大家对智能指针的使用更加融会贯通。
+本文深入讲解了何为循环引用以及如何使用 `Weak` 来解决，同时还结合 `Rc`、`RefCell`、`Weak` 等实现了两个有实战价值的例子，让大家对智能指针的使用更加融会贯通。
 
-至此，智能指针一章即将结束(严格来说还有一个Mutex放在多线程一章讲解)，而Rust语言本身的学习之旅也即将结束，后面我们将深入多线程、项目工程、应用实践、性能分析等特色专题，来一睹Rust在这些领域的风采。
+至此，智能指针一章即将结束（严格来说还有一个 `Mutex` 放在多线程一章讲解），而 Rust 语言本身的学习之旅也即将结束，后面我们将深入多线程、项目工程、应用实践、性能分析等特色专题，来一睹 Rust 在这些领域的风采。

contents/advance/circle-self-ref/self-referential.md

@@ -1,5 +1,5 @@
 ## 结构体自引用
-结构体自引用在Rust中是一个众所周知的难题，而且众说纷纭，也没有一篇文章能把相关的话题讲透，那本文就王婆卖瓜，来试试看能不能讲透这一块儿内容，让读者大大们舒心。
+结构体自引用在 Rust 中是一个众所周知的难题，而且众说纷纭，也没有一篇文章能把相关的话题讲透，那本文就王婆卖瓜，来试试看能不能讲透这一块儿内容，让读者大大们舒心。
 
 ## 平平无奇的自引用
 可能也有不少人第一次听说自引用结构体，那咱们先来看看它们长啥样。
@@ -12,7 +12,7 @@ struct RefWithinMe<'a> {
     pointer_to_value: &'a str,
 }
 ```
-以上就是一个很简单的自引用结构体,看上去好像没什么，那来试着运行下：
+以上就是一个很简单的自引用结构体，看上去好像没什么，那来试着运行下：
 ```rust
 fn main(){
     let s = "aaa".to_string();
@@ -23,7 +23,7 @@ fn main(){
 }
 ```
 
-运行后报错:
+运行后报错：
 ```console
  let v = SelfRef {
 12 |         value: s,
@@ -34,8 +34,8 @@ fn main(){
 
 因为我们试图同时使用值和值的引用，最终所有权转移和借用一起发生了。所以，这个问题貌似并没有那么好解决，不信你可以回想下自己具有的知识，是否可以解决？
 
-## 使用Option
-最简单的方式就是使用`Opiton`分两步来实现:
+## 使用 Option
+最简单的方式就是使用 `Opiton` 分两步来实现：
 ```rust
 #[derive(Debug)]
 struct WhatAboutThis<'a> {
@@ -54,7 +54,7 @@ fn main() {
 }
 ```
 
-在某种程度上来说，`Option`这个方法可以工作，但是这个方法的限制较多，例如从一个函数创建并返回它是不可能的:
+在某种程度上来说，`Option` 这个方法可以工作，但是这个方法的限制较多，例如从一个函数创建并返回它是不可能的：
 ```rust
 fn creator<'a>() -> WhatAboutThis<'a> {
     let mut tricky = WhatAboutThis {
@@ -67,7 +67,7 @@ fn creator<'a>() -> WhatAboutThis<'a> {
 }
 ```
 
-报错如下:
+报错如下：
 ```console
 error[E0515]: cannot return value referencing local data `tricky.name`
   --> src/main.rs:24:5
@@ -79,9 +79,9 @@ error[E0515]: cannot return value referencing local data `tricky.name`
    |     ^^^^^^ returns a value referencing data owned by the current function
 ```
 
-其实从函数签名就能看出来端倪，`'a`生命周期是凭空产生的！
+其实从函数签名就能看出来端倪，`'a` 生命周期是凭空产生的！
 
-如果是通过方法使用，你需要一个无用`&'a self`生命周期标识，一旦有了这个标识，代码将变得更加受限，你将很容易就获得借用错误，就连NLL规则都没用：
+如果是通过方法使用，你需要一个无用 `&'a self` 生命周期标识，一旦有了这个标识，代码将变得更加受限，你将很容易就获得借用错误，就连 NLL 规则都没用：
 ```rust
 #[derive(Debug)]
 struct WhatAboutThis<'a> {
@@ -107,8 +107,8 @@ fn main() {
 }
 ```
 
-## unsafe实现
-既然借用规则妨碍了我们，那就一脚踢开: 
+## unsafe 实现
+既然借用规则妨碍了我们，那就一脚踢开：
 ```rust
 #[derive(Debug)]
 struct SelfRef {
@@ -134,7 +134,8 @@ impl SelfRef {
     }
 
     fn pointer_to_value(&self) -> &String {
-        assert!(!self.pointer_to_value.is_null(), "Test::b called without Test::init being called first");
+        assert!(!self.pointer_to_value.is_null(),
+            "Test::b called without Test::init being called first");
         unsafe { &*(self.pointer_to_value) }
     }
 }
@@ -143,13 +144,13 @@ fn main() {
     let mut t = SelfRef::new("hello");
     t.init();
     // 打印值和指针地址
-    println!("{}, {:p}",t.value(), t.pointer_to_value());
+    println!("{}, {:p}", t.value(), t.pointer_to_value());
 }
 ```
 
-在这里，我们在`pointer_to_value`中直接存储原生指针，而不是Rust的引用，因此不再受到Rust借用规则和生命周期的限制，而且实现起来非常清晰、简洁。但是缺点就是，通过指针获取值时需要使用`unsafe`代码, 
+在这里，我们在 `pointer_to_value` 中直接存储原生指针，而不是 Rust 的引用，因此不再受到 Rust 借用规则和生命周期的限制，而且实现起来非常清晰、简洁。但是缺点就是，通过指针获取值时需要使用 `unsafe` 代码。
 
-当然，上面的代码你还能通过原生指针来修改`String`，但是需要将`*const`修改为`*mut`:
+当然，上面的代码你还能通过原生指针来修改 `String`，但是需要将 `*const` 修改为 `*mut`：
 ```rust
 #[derive(Debug)]
 struct SelfRef {
@@ -183,36 +184,36 @@ impl SelfRef {
 fn main() {
     let mut t = SelfRef::new("hello");
     t.init();
-    println!("{}, {:p}",t.value(), t.pointer_to_value());
+    println!("{}, {:p}", t.value(), t.pointer_to_value());
 
     t.value.push_str(", world");
     unsafe {
         (&mut *t.pointer_to_value).push_str("!");
     }
 
-    println!("{}, {:p}",t.value(), t.pointer_to_value());
+    println!("{}, {:p}", t.value(), t.pointer_to_value());
 }
 ```
-运行后输出:
+运行后输出：
 ```console
 hello, 0x16f3aec70
 hello, world!, 0x16f3aec70
 ```
 
-上面的`unsafe`虽然简单好用，但是它不太安全，是否还有其他选择？还真的有，那就是`Pin`。
+上面的 `unsafe` 虽然简单好用，但是它不太安全，是否还有其他选择？还真的有，那就是 `Pin`。
 
-## 无法被移动的Pin
-Pin在后续章节会深入讲解，目前你只需要知道它可以固定住一个值，防止该值在内存中被移动。
+## 无法被移动的 Pin
+`Pin` 在后续章节会深入讲解，目前你只需要知道它可以固定住一个值，防止该值在内存中被移动。
 
-通过开头我们知道，自引用最麻烦的就是创建引用的同时，值的所有权会被转移，而通过Pin就可以很好的防止这一点:
+通过开头我们知道，自引用最麻烦的就是创建引用的同时，值的所有权会被转移，而通过 `Pin` 就可以很好的防止这一点：
 ```rust
 use std::marker::PhantomPinned;
 use std::pin::Pin;
 use std::ptr::NonNull;
 
-// 下面是一个自引用数据结构体，因为slice字段是一个指针, 指向了data字段
-// 我们无法使用普通引用来实现，因为违背了Rust的编译规则
-// 因此，这里我们使用了一个原生指针，通过NonNull来确保它不会为null
+// 下面是一个自引用数据结构体，因为 slice 字段是一个指针，指向了 data 字段
+// 我们无法使用普通引用来实现，因为违背了 Rust 的编译规则
+// 因此，这里我们使用了一个原生指针，通过 NonNull 来确保它不会为 null
 struct Unmovable {
     data: String,
     slice: NonNull<String>,
@@ -220,7 +221,7 @@ struct Unmovable {
 }
 
 impl Unmovable {
-    // 为了确保函数返回时数据的所有权不会被转移, 我们将它放在堆上, 唯一的访问方式就是通过指针
+    // 为了确保函数返回时数据的所有权不会被转移，我们将它放在堆上，唯一的访问方式就是通过指针
     fn new(data: String) -> Pin<Box<Self>> {
         let res = Unmovable {
             data,
@@ -246,20 +247,20 @@ fn main() {
     let mut still_unmoved = unmoved;
     assert_eq!(still_unmoved.slice, NonNull::from(&still_unmoved.data));
 
-    // 因为我们的类型没有实现`Unpin`特征，下面这段代码将无法编译
+    // 因为我们的类型没有实现 `Unpin` 特征，下面这段代码将无法编译
     // let mut new_unmoved = Unmovable::new("world".to_string());
     // std::mem::swap(&mut *still_unmoved, &mut *new_unmoved);
 }
 ```
 
-上面的代码也非常清晰，虽然使用了`unsafe`，其实更多的是无奈之举，跟之前的`unsafe`实现完全不可同日而语。
+上面的代码也非常清晰，虽然使用了 `unsafe`，其实更多的是无奈之举，跟之前的 `unsafe` 实现完全不可同日而语。
 
-其实`Pin`在这里并没有魔法，它也并不是实现自引用类型的主要原因，最关键的还是里面的原生指针的使用，而`Pin`起到的作用就是确保我们的值不会被移走，否则指针就会指向一个错误的地址！
+其实 `Pin` 在这里并没有魔法，它也并不是实现自引用类型的主要原因，最关键的还是里面的原生指针的使用，而 `Pin` 起到的作用就是确保我们的值不会被移走，否则指针就会指向一个错误的地址！
 
 
 
-## 使用ouroboros
-对于自引用结构体，三方库也有支持的，其中一个就是[ouroboros](https://github.com/joshua-maros/ouroboros)，当然它也有自己的限制，我们后面会提到，先来看看该如何使用：
+## 使用 ouroboros
+对于自引用结构体，三方库也有支持的，其中一个就是 [ouroboros](https://github.com/joshua-maros/ouroboros)，当然它也有自己的限制，我们后面会提到，先来看看该如何使用：
 ```rust
 use ouroboros::self_referencing;
 
@@ -286,11 +287,11 @@ fn main(){
 }
 ```
 
-可以看到，`ouroboros`使用起来并不复杂，就是需要你去按照它的方式创建结构体和引用类型：`SelfRef`变成`SelfRefBuilder`，引用字段从`pointer_to_value`变成`pointer_to_value_builder`，并且连类型都变了。
+可以看到，`ouroboros` 使用起来并不复杂，就是需要你去按照它的方式创建结构体和引用类型：`SelfRef` 变成 `SelfRefBuilder`，引用字段从 `pointer_to_value` 变成 `pointer_to_value_builder`，并且连类型都变了。
 
-在使用时，通过`borrow_value`来借用`value`的值，通过`borrow_pointer_to_value`来借用`pointer_to_value`这个指针。
+在使用时，通过 `borrow_value` 来借用 `value` 的值，通过 `borrow_pointer_to_value` 来借用 `pointer_to_value` 这个指针。
 
-看上去很美好对吧？但是你可以尝试着去修改`String`字符串的值试试，`ouroboros`限制还是较多的，但是对于基本类型依然是支持的不错，以下例子来源于官方:
+看上去很美好对吧？但是你可以尝试着去修改 `String` 字符串的值试试，`ouroboros` 限制还是较多的，但是对于基本类型依然是支持的不错，以下例子来源于官方：
 ```rust
 use ouroboros::self_referencing;
 
@@ -331,19 +332,19 @@ fn main() {
 }
 ```
 
-总之，使用这个库前，强烈建议看一些官方的例子中支持什么样的类型和API，如果能满足的你的需求，就果断使用它，如果不能满足，就继续往下看。
+总之，使用这个库前，强烈建议看一些官方的例子中支持什么样的类型和 API，如果能满足的你的需求，就果断使用它，如果不能满足，就继续往下看。
 
-只能说，它确实帮助我们解决了问题，但是一个是破坏了原有的结构，另外就是并不是所有数据类型都支持：它需要目标值的内存地址不会改变，因此`Vec`动态数组就不适合，因为当内存空间不够时，Rust会重新分配一块空间来存放该数组，这会导致内存地址的改变。 
+只能说，它确实帮助我们解决了问题，但是一个是破坏了原有的结构，另外就是并不是所有数据类型都支持：它需要目标值的内存地址不会改变，因此 `Vec` 动态数组就不适合，因为当内存空间不够时，Rust 会重新分配一块空间来存放该数组，这会导致内存地址的改变。
 
-类似的库还有:
+类似的库还有：
 - [rental](https://github.com/jpernst/rental)， 这个库其实是最有名的，但是好像不再维护了，用倒是没问题
-- [owning-ref](https://github.com/Kimundi/owning-ref-rs) ，将所有者和它的引用绑定到一个封装类型
+- [owning-ref](https://github.com/Kimundi/owning-ref-rs)，将所有者和它的引用绑定到一个封装类型
 
-这三个库，各有各的特点，也各有各的缺陷，建议大家需要时，一定要仔细调研，并且写demo进行测试，不可大意。
+这三个库，各有各的特点，也各有各的缺陷，建议大家需要时，一定要仔细调研，并且写 demo 进行测试，不可大意。
 
-> rental虽然不怎么维护，但是可能依然是这三个里面最强大的，而且网上的用例也比较多，容易找到参考代码
+> rental 虽然不怎么维护，但是可能依然是这三个里面最强大的，而且网上的用例也比较多，容易找到参考代码
 
-## Rc+RefCell或Arc+Mutex
+## Rc + RefCell 或 Arc + Mutex
 
 类似于循环引用的解决方式，自引用也可以用这种组合来解决，但是会导致代码的类型标识到处都是，大大的影响了可读性。
 
@@ -352,7 +353,7 @@ fn main() {
 
 
 ## 学习一本书：如何实现链表
-最后，推荐一本专门将如何实现链表的书(真是富有Rust特色，链表都能复杂到出书了O, O)，[Learn Rust by writing Entirely Too Many Linked Lists](https://rust-unofficial.github.io/too-many-lists/)
+最后，推荐一本专门将如何实现链表的书（真是富有 Rust 特色，链表都能复杂到出书了o_o），[Learn Rust by writing Entirely Too Many Linked Lists](https://rust-unofficial.github.io/too-many-lists/)
 
 
 ## 总结