在Rust中能否为尝试实现子trait的类型blanket实现其父trait？

嘿，这个问题问到了Rust trait系统里一个挺有意思的角落！先看你给出的这段代码，现在的Rust编译器确实能让它正常编译并运行：

trait Trait1: Trait2 {}
trait Trait2 {}
impl<T: Trait1> Trait2 for T {}
impl<T> Trait1 for T {}

fn main() {
    let t: Box<dyn Trait1> = Box::new(());
}

你肯定会觉得这逻辑像个死循环对吧？毕竟：

• Trait1 作为子trait，要求实现它的类型必须先实现 Trait2
• 但我们又写了一个全局实现（blanket impl），给所有已实现 Trait1 的类型自动补上 Trait2 的实现
• 最后还给所有类型都全局实现了 Trait1

这看起来完全是循环论证嘛！那为什么Rust还允许它通过呢？

其实这是因为Rust的trait约束检查是“延迟验证”的——它不会在定义这些impl的时候就立刻卡死所有约束，而是等到具体类型被实际使用的时候，才会递归地验证整个约束链能不能形成闭环。拿代码里的()类型举例子：

1. 我们要为()实现Trait1，这要求()必须先有Trait2的实现
2. 而()此时已经满足T: Trait1的条件（因为我们正在为它实现这个trait），所以能通过那个全局impl自动获得Trait2的实现
3. 这样两个约束就互相补全了，形成了一个合法的闭环

至于这是不是Rust有意设计的行为？答案是肯定的——这种循环的全局impl在某些场景下是实用的，Rust的类型检查器专门做了处理来支持这种合法的递归约束场景，只要最终对于具体类型来说，整个约束链能被完整证明，就会被允许通过。

备注：内容来源于stack exchange，提问作者ais523