答案。

问题的历史

Rust的主要目标之一是防止对不可变数据的修改，并在编译阶段避免数据竞争。在普通情况下，Rust不允许通过不可变引用来修改数据。然而，在需要通过引用修改内部状态的缓存系统、惰性计算或逻辑中，这有时是必要的。因此，出现了内部可变性模式。

问题

没有内部可变性，实现缓存、惰性初始化和许多其他习语变得困难或不可能，同时保持安全的所有权和引用。经典示例是一个函数内部的缓存，它只向外界提供不可变的自身引用。

解决方案

在Rust中，有一些特殊类型——Cell和RefCell（以及它们的多线程版本），它们允许通过不可变引用修改内部值，同时在运行时控制安全性，而不是在编译时。

Cell<T>——复制原语，允许在不使用引用的情况下修改或读取值，仅适用于实现Copy的类型。
RefCell<T>——即使只有不可变的外部引用，也允许“即时”获取可变引用，但如果尝试同时获取两个可变引用或一个可变和多个不可变引用，则会在运行时发生恐慌。

示例代码：

use std::cell::RefCell;

struct Foo {
    cache: RefCell<Option<u32>>,
}

impl Foo {
    fn get_or_compute(&self) -> u32 {
        if let Some(val) = *self.cache.borrow() {
            return val;
        }
        let computed = 42;
        *self.cache.borrow_mut() = Some(computed);
        computed
    }
}

关键特性：

允许在对象内部修改数据，即使周围一切都被声明为不可变
违反所有权和引用规则只在运行时可能发生（通过恐慌），因此需要小心
主要类型：Cell、RefCell（单线程环境）、Mutex、RwLock（多线程）

误导性问题。

我们可以安全地在多线程结构中使用RefCell吗？

不行，RefCell不是线程安全的。在多线程环境中使用Mutex或RwLock。

可以返回对Cell<T>内容的引用吗？

不可以，Cell不会返回任何引用，只会复制或更新值。只适用于Copy类型，对于其他类型使用RefCell。

如果在同一个RefCell上连续调用borrow_mut会发生什么？

会在运行时发生恐慌，因为RefCell跟踪活动引用的数量。第二次尝试在已有引用的情况下获取可变访问将导致恐慌。

常见错误和反模式

在全局或静态上下文中存储RefCell，并忘记其单线程特性
不合理地使用RefCell而不是可变所有权和引用，使代码复杂且减慢
忽视在RefCell内处理恐慌

实例

消极案例

在项目中，总是使用RefCell来存储结构中的任何可变状态，即使可以使用可变所有权。代码变得冗长，运行时出现恐慌，测试变得困难。

优点： 可以快速绕过编译器的限制并实现期望的行为。

缺点： 执行阶段高错误风险，应用程序崩溃，调试逻辑困难。

积极案例

RefCell仅用于在大型结构中实现惰性缓存，其余代码保持经典的所有权和引用。所有值都被正确清理，没有恐慌。

优点： 逻辑透明，最小化使用内部可变性，代码稳定且可预测。

缺点： 需要关注数据修改的边界：读取缓存始终是安全的，写入仅在必要时且在狭窄的特定位置进行。

什么是Rust中的内部可变性，Cell和RefCell是如何允许在不可变结构内修改数据的？

答案。