当不可变引用可以完成这项工作时，为什么我们需要 Rc？

为了说明必要性Rc<T>, the Book https://doc.rust-lang.org/book/ch15-04-rc.html呈现以下代码片段（剧透：它不会编译）以表明我们无法在没有Rc<T>.

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

use crate::List::{Cons, Nil};

fn main() {
    let a = Cons(5, Box::new(Cons(10, Box::new(Nil))));
    let b = Cons(3, Box::new(a));
    let c = Cons(4, Box::new(a));
}

然后它声称（强调我的）

我们可以改变的定义Cons来保存引用，但是我们必须指定生命周期参数。通过指定生命周期参数，我们将指定列表中的每个元素的生存时间至少与整个列表一样长。借用检查器不允许我们编译let a = Cons(10, &Nil);例如，因为临时Nil在 a 引用它之前， value 将被删除。

嗯，不完全是。以下代码片段在下编译rustc 1.52.1

enum List<'a> {
    Cons(i32, &'a List<'a>),
    Nil,
}

use crate::List::{Cons, Nil};

fn main() {
    let a = Cons(5, &Cons(10, &Nil));
    let b = Cons(3, &a);
    let c = Cons(4, &a);
}

请注意，通过引用，我们不再需要Box<T>间接保存嵌套List。此外，我可以指出b and c to a， 这使a多个概念所有者（实际上是借款人）。

问题：为什么我们需要Rc<T>不可变引用什么时候可以完成这项工作？

通过“普通”借用，您可以非常粗略地想到静态证明的按关系排序，其中编译器需要证明某物的所有者always在任何借用之前就已生效always所有借款都死后就死了（a owns String，它之前就复活了b哪个借用a, then b死了，然后a死亡；有效的）。对于很多用例来说，这是可以做到的，这是 Rust 使借用系统变得实用的洞察力。

在某些情况下，这无法静态完成。在您给出的示例中，您有点作弊，因为所有借用都有一个'static-寿命;和'static因此，项目可以在任何无限之前或之后“排序” - 所以实际上首先没有任何限制。当你采用不同的生命周期（许多List<'a>, List<'b>等）考虑在内。当您尝试将值传递给函数并且这些函数尝试添加项目时，此问题将变得明显。这是因为在函数内部创建的值在离开其作用域后（即当封闭函数返回时）将会消失，因此我们不能在之后保留对它们的引用，否则将会出现悬空引用。

Rc当一个人无法静态地证明谁是原始所有者，其生命周期在任何其他人之前开始并在任何其他人之后结束时（！），就会出现。一个典型的例子是从用户输入派生的图形结构，其中多个节点可以引用另一个节点。它们需要与它们在运行时引用的节点形成“生于之后，死于之前”的关系，以保证它们永远不会引用无效数据。这Rc是一个非常简单的解决方案，因为一个简单的计数器就可以表示这些关系。只要计数器不为零，some“生于之后，死于之前”的关系仍然活跃。这里的关键见解是，这并不重要按什么顺序节点的创建和消亡是因为any订单有效。只有两端的点（计数器为 0 的地方）实际上很重要，其间的任何增加或减少都是相同的（0=+1+1+1-1-1-1=0是相同的0=+1+1-1+1-1-1=0) The Rc当计数器达到零时被销毁。在图表示例中，这是当不再引用节点时。这告诉了它的主人Rc（最后一个节点指的是）“哦，事实证明I我是底层节点的所有者 - 没有人知道！ - 我要摧毁它”。