为何两处DynClone Trait实现不冲突？及Box默认未实现Trait的技术咨询

嗨，我来帮你拆解这两个问题哈～

一、为什么两处DynClone实现不会冲突？ #

先看你代码里的实现：impl<T: Any + Clone + 'static> DynClone for T，这是Rust里的blanket实现——也就是给所有满足约束条件（Any + Clone + 'static）的类型自动套上DynClone的实现。

这种实现和其他具体类型的实现（比如你之后可能想写的impl DynClone for Box<dyn DynClone>）不会冲突，原因是Rust的trait实现优先级规则：具体类型的实现优先级高于泛型的blanket实现。当编译器需要判断某个类型是否实现了DynClone时，会先找有没有针对该类型的专属实现，如果没有，才会去匹配blanket实现。所以只要你后续的实现是针对具体类型的（比如Box包裹的trait对象），就不会和这个全局的泛型实现打架。

二、为什么Box默认不实现对应的Trait？ #

你遇到的问题是：拿着Box<dyn SubTrait>去调用一个期望接收impl SubTrait的函数，结果报错说Box没实现SubTrait。这是Rust的设计决定——Trait不会自动被包裹它的Box继承，原因主要有这几点：

• Rust强调“显式优于隐式”：Box是一个智能指针，它本身和内部包裹的类型是两个不同的东西。自动实现Trait可能会违背开发者的预期，比如有些Trait的语义是针对值本身的，而不是指针。
• 避免歧义：如果自动为Box实现所有T的Trait，可能会导致某些场景下编译器无法确定该使用哪个实现（比如当Box本身也有自己的Trait实现时）。

那怎么解决这个问题呢？你只需要手动为Box<dyn SubTrait>实现对应的Trait就行：

// 先实现SubTrait
impl SubTrait for Box<dyn SubTrait> {}

// 再实现DynClone，因为SubTrait继承自DynClone
impl DynClone for Box<dyn SubTrait> {
    fn dyn_clone(&self) -> Box<dyn DynClone> {
        // 调用内部对象的dyn_clone方法，返回的Box可以自动转为Box<dyn DynClone>
        (**self).dyn_clone()
    }
}

这样之后，Box<dyn SubTrait>就会被当作SubTrait的实现者，能正常传入期望impl SubTrait的函数里啦～

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