Rust中带指定生命周期的相互引用结构体为何可行？代码编译原因及生命周期疑惑解析

一、初始代码为何能编译通过？ #

先贴出你的初始代码：

use core::cell::Cell;
struct Shop<'a> {
    barber: Cell<Option<&'a Barber<'a>>>,
}
struct Barber<'a> {
    shop: Cell<Option<&'a Shop<'a>>>,
}
fn main() {
    let shop = Shop { barber: Cell::new(None) };
    {
        let barber = Barber { shop: Cell::new(Some(&shop))};
        shop.barber.set(Some(&barber));
    }
}

你的初始直觉是对的——这段代码确实存在潜在的悬垂引用风险，但编译器允许它通过的核心原因在于生命周期参数的推断逻辑：

• 这里的'a是同时约束Shop和Barber中引用的生命周期参数。编译器会把'a推断为内部块中barber的生命周期（也就是从barber声明到内部块结束的这段时间）。
• 对于Barber<'a>中的&'a Shop<'a>引用，shop的生命周期明显长于'a（shop在外部作用域，直到main结束才销毁），完全满足“引用的生命周期不超过被引用对象的生命周期”的规则。
• 当你执行shop.barber.set(Some(&barber))时，&barber的生命周期正好是'a，也符合Shop<'a>字段的类型要求。

那为什么没触发“生命周期不足”的错误？因为编译器只检查引用在其声明的生命周期内是否有效，而不会主动阻止你在生命周期结束后持有悬垂引用。如果在内部块结束后尝试访问shop.barber里的引用，比如添加：

// 内部块结束后
shop.barber.get().unwrap();

编译器立刻会抛出错误，因为此时'a生命周期已经结束，引用已经失效。

二、同一作用域内变量的生命周期与销毁顺序 #

针对你的补充代码，这里明确两个关键概念：

1. 同一作用域内变量的生命周期 #

同一作用域内声明的变量，它们的**引用有效期（即生命周期）**是从各自的声明点开始，直到整个作用域结束。编译器会认为这些变量的生命周期是重叠的，因此相互引用时，只要类型中的生命周期参数被推断为整个作用域的生命周期，就不会有编译错误。

比如你的补充代码中，shop和barber都在main的顶层作用域，编译器会把'a推断为main函数的整个生命周期，所以&shop和&barber的生命周期都满足'a的要求，相互引用完全合法。

2. 销毁顺序与Drop trait的关系 #

变量的销毁顺序确实是声明的逆序，这个规则是Rust的默认行为，无论是否实现Drop trait。但两者的区别在于：

• 如果没有实现Drop，编译器不会强制检查销毁顺序带来的引用安全性。比如你的补充代码中，barber先被销毁（因为后声明），此时它持有的&shop引用还是有效的（shop还没销毁）；之后shop被销毁，它持有的&barber引用已经失效，但因为Shop没有实现Drop，销毁时不会访问这个引用，所以运行时不会出问题。
• 如果实现了Drop，编译器会严格检查：如果两个结构体相互引用且都实现Drop，编译器会直接报错。因为它无法保证销毁顺序不会导致悬垂引用（比如Shop持有Barber的引用，Shop先销毁的话，Drop方法中可能访问已经销毁的Barber）。

举个例子，给Shop和Barber添加Drop实现：

impl<'a> Drop for Shop<'a> {
    fn drop(&mut self) {}
}

impl<'a> Drop for Barber<'a> {
    fn drop(&mut self) {}
}

此时你的补充代码会编译失败，因为编译器无法确定销毁顺序是否安全——无论先销毁哪一个，都会导致另一个持有的引用在drop时可能失效。

内容的提问来源于stack exchange，提问作者Oyren