为何Rust中不对原始类型引用执行隐式解引用？

首先得明确：Rust对所有引用类型的隐式解引用（直接将&T转换为T）都做了限制，不管T是不是原始类型，这背后主要是几个设计层面的考量：

1. 语言规则的一致性 #

Rust的设计哲学之一是避免特例。如果只为原始类型开放隐式解引用，用户自然会疑惑：为什么自定义的Copy类型（比如#[derive(Copy, Clone)] struct MyInt(i32);）不能享受同样的待遇？维护一套统一的规则，既能降低编译器的实现复杂度，也能减少开发者的学习成本——不用记哪些类型能隐式解引用，哪些不行。

2. 避免代码歧义与可读性下降 #

隐式解引用会模糊代码的意图。比如：

let num = 42;
let ref_num = #
let val: i32 = ref_num; // 若允许隐式解引用，这里能直接赋值

看起来简单，但在复杂场景中，比如嵌套引用、混合多种类型的表达式，隐式解引用会让读者难以快速判断当前操作的是引用还是值。Rust更倾向于显式表达意图，用*ref_num明确表示解引用，代码的可读性和可维护性更高。

3. 潜在的歧义场景 #

就算是原始类型，隐式解引用也可能引发意外问题，比如函数重载的解析歧义：

fn handle(x: &i32) { println!("处理引用"); }
fn handle(x: i32) { println!("处理值"); }

let x = &42;
handle(x); // 当前会调用&i32版本
// 若允许隐式解引用，编译器无法确定应该调用哪个版本

这种歧义会破坏代码的确定性，而Rust始终优先保证代码行为的可预测性。

4. 并非未实现的功能 #

这不是编译器的缺失，而是刻意的设计选择。Rust允许通过Deref trait实现自动解引用（比如智能指针Box<T>、Rc<T>在方法调用时会自动解引用），但这种自动解引用是有明确规则的（仅在调用方法、访问字段等场景触发），而非直接允许&T到T的隐式类型转换——哪怕T是Copy类型。

总结来说，禁止原始类型的隐式解引用，是为了维护语言的一致性、代码的可读性和行为的确定性，和Copy语义本身无关。

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