为何Rust中的`Cell<T>`未实现`Deref` trait？

架构老林

2026-7-11

为什么Cell<T>不实现Deref trait？

Cell<T>不实现Deref的核心原因是严格维护内部可变性的安全访问规则，避免隐式操作绕过其设计的安全边界，具体可以从以下几点理解：

防止不可变引用的非法逃逸
如果为Cell<T>实现Deref<Target=T>，持有&Cell<T>时会自动解引用得到&T——这相当于直接获取了内部值的不可变引用。但Cell<T>的设计逻辑是所有对内部值的访问都必须通过get/set/replace这类显式方法，确保修改操作都经过它的内部可变性管控。一旦允许&T直接被获取，就可能出现该引用被长期持有，同时其他地方通过Cell修改内部值的场景，这会违背Rust的借用规则（不可变引用与可变操作共存），破坏Cell<T>的安全语义。
避免可变性语义混淆
Cell<T>的核心特性是持有不可变引用时也能修改内部值，这和普通类型的可变性逻辑完全相反。如果实现Deref，用户很容易误以为&Cell<T>解引用后的&T和普通不可变引用一样，不能被修改，但实际上Cell<T>允许在持有&Cell<T>时修改内部值，这种认知偏差会导致代码行为不符合预期。比如：
```
let cell = Cell::new(5);
let ref_val = &*cell; // 若实现Deref，这里会得到&i32
cell.set(6); // 此时ref_val指向的值已被修改，违背不可变引用的直觉
```
与RefCell<T>的设计边界区分
RefCell<T>实现了Deref和DerefMut，但它依赖运行时借用检查来保证安全；而Cell<T>针对Copy或可移动类型设计，通过复制/替换实现内部可变性，无需运行时开销。为Cell<T>实现Deref会模糊两者的使用场景，让开发者混淆不同内部可变性类型的适用范围。
遵循“最小惊喜”设计原则
Rust标准库的API设计非常强调明确性，Cell<T>刻意限制访问方式，就是为了让开发者清晰意识到自己在使用内部可变性，而非通过隐式解引用无意中触发非预期行为。所谓的“使用便利”会牺牲这种明确性，引入潜在的安全风险，不符合标准库的设计理念。