一、为什么需要内部可变性？
通常，Rust 编译器通过静态分析确保：
- 同一时刻只能存在一个可变引用，或任意多个不可变引用；
- 引用始终保持有效。
这种严格的借用规则使得许多内存错误在编译阶段就能被捕获，但也因此在某些场景下过于保守。例如，当我们需要在不可变对象的内部修改状态时（比如记录日志、计数等），就需要借助内部可变性。通过内部可变性，我们可以在外部保持不可变的同时，通过封装的方式实现内部数据的变更，而这些变更的安全性则由运行时检查保证。
二、RefCell<T>：运行时借用规则的守护者
与 Box<T> 和 Rc<T> 不同，RefCell<T> 使用运行时而非编译时来检查借用规则。它提供了两个核心方法：
borrow()返回一个Ref<T>智能指针，相当于不可变引用。borrow_mut()返回一个RefMut<T>智能指针，相当于可变引用。
每当调用 borrow 或 borrow_mut 时，RefCell<T> 都会在内部记录当前的借用状态。如果试图同时获取多个可变引用，或者在已有可变引用的情况下获取不可变引用，RefCell<T> 将在运行时触发 panic，从而防止数据竞争。
例如，下述代码尝试在同一作用域内创建两个可变借用，就会触发 panic：
let cell = RefCell::new(5);
let _borrow1 = cell.borrow_mut();
let _borrow2 = cell.borrow_mut(); // 此处将 panic: already borrowed: BorrowMutError
这种设计的优点在于，它允许我们在某些静态检查无法覆盖的场景下依然保证数据安全；缺点则是这些检查会带来一定的运行时开销，同时可能将错误暴露在生产环境中。
三、实际案例：使用 RefCell<T> 编写 Mock 对象
在测试代码中，我们常常需要模拟一些真实对象的行为（即所谓的“测试替身”或 mock 对象），以验证代码逻辑是否正确。假设我们有一个 Messenger 接口，其 send 方法只接受不可变引用。这在编写 mock 对象时会带来问题：我们希望在调用 send 时记录下发送的信息，但由于方法签名只接受 &self，直接修改内部状态会违反 Rust 的借用规则。
解决方案是使用 RefCell<T> 来包装内部的可变状态。例如，我们可以这样定义一个 MockMessenger：
struct MockMessenger {sent_messages: RefCell<Vec<String>>,
}impl MockMessenger {fn new() -> MockMessenger {MockMessenger {sent_messages: RefCell::new(vec![]),}}
}impl Messenger for MockMessenger {fn send(&self, message: &str) {// 虽然 `self` 是不可变引用，但我们可以通过 `RefCell<T>` 在运行时获取可变引用self.sent_messages.borrow_mut().push(String::from(message));}
}
这样，在测试中，我们可以通过调用 borrow() 来检查内部保存的消息，而无需修改 Messenger trait 的定义。RefCell<T> 的内部借用计数确保了我们在使用时不会违反借用规则。
四、结合 Rc<T> 实现多所有权的可变数据
有时我们希望多个所有者可以共享同一份数据，并且能够修改其中的值。这时可以结合使用 Rc<T> 和 RefCell<T>。Rc<T> 允许多个所有者共享数据，而 RefCell<T> 则允许我们在不可变引用的上下文中修改数据。
例如，下例展示了如何创建一个共享的可变值，并通过多个所有者修改它：
use std::rc::Rc;
use std::cell::RefCell;enum List {Cons(Rc<RefCell<i32>>, Rc<List>),Nil,
}use List::{Cons, Nil};fn main() {let value = Rc::new(RefCell::new(5));let a = Rc::new(Cons(Rc::clone(&value), Rc::new(Nil)));let b = Cons(Rc::clone(&value), Rc::clone(&a));let c = Cons(Rc::clone(&value), Rc::clone(&a));// 修改内部值*value.borrow_mut() += 10;// 输出 a, b, c 中存储的值都会反映内部值的改变println!("a after modification: {:?}", a);
}
通过这种方式，我们既能享受多所有权的便利，又能保持内部数据的可变性。这在需要共享状态的场景下非常有用，但需要注意的是，这种模式仅适用于单线程场景；如果在多线程环境中，则应使用 Mutex<T> 等线程安全的数据结构。
五、总结
- 内部可变性：允许在不可变引用中修改内部数据。通过封装
unsafe代码，将运行时检查借用规则的责任交给RefCell<T>。 - RefCell 的特点：在运行时记录不可变与可变借用的状态，一旦违反借用规则会导致 panic。这为某些静态检查无法覆盖的场景提供了解决方案。
- 应用场景：
- Mock 对象：在测试中记录调用信息，满足接口要求而无需修改方法签名。
- 多所有权与可变性结合：结合
Rc<T>和RefCell<T>，可以实现多个所有者共享并修改数据，但仅适用于单线程环境。
内部可变性为 Rust 程序员提供了一种在严格的编译时借用检查之外，依然保持内存安全的灵活方案。只需谨慎使用，理解其运行时检查的局限性，即可在设计上更好地解决某些复杂场景的问题。
希望这篇博客能够帮助你更好地理解 RefCell<T> 及其在 Rust 中的实际应用。如果你有更多问题或想讨论更多细节，欢迎在评论区交流！