trait 与泛型：行为的抽象

enum 和 struct 组织数据，trait 组织行为。trait 定义一组方法签名，任何类型都可以实现它；泛型让函数在「实现了某 trait 的任何类型」上工作。两者合起来就是 Rust 的多态：编译期静态分发，或 trait 对象的动态分发。这篇讲 trait 定义、实现、泛型约束、以及两种分发的性能取舍。

一、定义与实现

trait 用 trait 关键字声明方法签名，impl 块里写成 impl Trait for Type。实现必须恰好一次，且要么定义在类型所在的 crate，要么 trait 来自外部——这叫孤儿规则，防止两个库给同一类型实现同一 trait 互相冲突。

trait Greet {
    fn name(&self) -> &str;
    // 默认实现：实现者可以不重写
    fn say_hi(&self) {
        println!("你好，{}", self.name());
    }
}

struct Student { n: String }

impl Greet for Student {
    fn name(&self) -> &str { &self.n } // 只需实现无默认的方法
}

默认方法是 trait 的便利之一：签名定契约、默认给兜底，实现者按需覆盖。这与某些语言接口不能带实现的限制形成鲜明对比，既保统一又省样板。

再讲一条关联规则：trait 方法之间可以互相调用，默认实现里调签名方法很常见，上例 say_hi 调 name 就是。实现者只需提供底层零件，组合逻辑由默认方法统一，改动行为时一处修改全部生效——这是 trait 胜过纯函数集合的设计力量，也是标准库能把 Iterator 写成几十个默认方法全靠 next 一个签名的原因。

二、泛型与 trait 约束

泛型函数默认什么类型参数都能传，能力太大反而危险，所以要用 trait 约束收窄。约束写在尖括号里或 where 子句里，函数体因此只能调用约束里的方法。

// 两种等价写法
fn longest<T: PartialOrd>(a: T, b: T) -> T {
    if a < b { b } else { a }
}

fn sum_all<T>(xs: &[T]) -> T
where
    T: Sum,
{
    xs.iter().sum()
}

设计直觉：约束写最小够用的 trait，函数通用性最强。一上来 T: Debug + Clone + Display 全加上，等于把未来只缺一个 trait 的类型挡在门外。这也类似接口隔离原则：要的是「能比较」就别要求「能打印」。

泛型的成本模型也顺带说明：单态化按具体类型复制代码，编译慢一些、二进制大一些，换来运行时零开销。这就是教科书「零成本抽象」在 Rust 里的具体含义——抽象的代价转移到了编译环节，而非每次调用。对于热点循环里的泛型函数，这个差别是决定性的。

三、静态分发与 trait 对象

impl Trait 与泛型同属静态分发：编译器为每个具体类型生成一份代码，调用是直接跳转，零运行时成本。dyn Trait 则是动态分发：通过虚表在运行时查方法，一份代码服务所有类型，代价是间接调用与无法内联。

// 静态分发：编译期单态化
fn print_all<T: Greet>(items: &[T]) {
    for i in items { i.say_hi(); }
}

// 动态分发：异构集合必须走这条路
fn print_dyn(items: &[Box<dyn Greet>]) {
    for i in items { i.say_hi(); }
}

选择标准很实际：同一类型的集合用泛型；一个集合里要混放不同类型（Student 和 Teacher 都放进一个 Vec）就必须 Box<dyn Trait>。 Sized 约束是这里的细节——trait 对象要求类型大小已知， trait 自身默认有 Sized 约束，需要 ?Sized 才能写 &dyn Trait 这类用法。

四、常见标准库 trait

日常编码绕不开四个：Display 与 Debug 管打印、PartialEq 管比较、Clone 管复制、From/Into 管转换。它们大多有派生宏，一行属性搞定。手写时注意 Display 面向终端用户、Debug 面向开发者，两者不必一致。

impl std::fmt::Display for Student {
    fn fmt(&self, f: &mut std::fmt::Formatter) -> std::fmt::Result {
        write!(f, "学生({})", self.n)
    }
}

From 与 Into 的对称性值得记住：实现了 From 就免费得到 Into（标准库的 blanket impl）。写转换时给「源类型」写 From，下游 let t: T = x.into(); 自动可用。这与 ? 的自动 From 转换是同一套机制在两处发力。

另一对高频 trait 是 TryFrom/TryInto，对应可能失败的转换。From 表达「一定成功」，TryFrom 表达「可能失败」，语义分界同样是错误处理一章的归因原则。给数值向下转型加 TryFrom 而不是 as 强转，能拿到溢出错误而非静默环绕，是库里推荐的做法。

五、trait 约束的典型错误

新手最常见的报错是 the trait bound is not satisfied：调用了某个 trait 方法却忘了加约束。修复方式两步：看错误信息里缺哪个 trait，回到函数签名补上 bound。另一个常见错误是孤儿规则冲突：给外部类型实现外部 trait，编译器直接拒绝。

一个不那么显眼的陷阱：泛型约束里的 trait 不能与实现的隐含需求矛盾。例如写 T: Ord 后又期望 T 支持 +=——那是另一个 trait（AddAssign）。报错信息通常很精确，逐字读它的 the trait bound 那行就能定位。

还有一个进阶要点：trait 可以带关联类型（type Item），与泛型参数的差别是「每个实现只有一种具体选择」。Iterator 的 associated type Item 就是这样：一个集合的迭代器产出类型固定，无需调用者再指定。用泛型参数会让同一类型可以实现多次同一 trait，关联类型则禁止这种多实现——前者要灵活、后者要唯一，按需求选。

六、速查与心法

trait 的心法一句话：先写具体类型，等第二、第三个类型出现并重复了同样的逻辑，再抽象出 trait。过早抽象的 trait 往往预测错需求方向。设计公开 API 时 trait 的默认方法等于给使用者的升级礼物：往后加默认方法不破坏已有实现。

trait 的命名也有一套不成文传统：行为 trait 用动词或形容词（Display、Clone、Iterator），转换 trait 用 From/Into 表方向，标记 trait（Send、Sync）用短词只表达属性。读标准库 trait 名单时这套规律会帮你快速分类，自己起名时也按这个谱系走，他人读你的代码会顺畅很多。

想把现有代码抽象成 trait，Claude Code 使用指南 里有按重复函数签名提取 trait 边界的重构流程。trait 在实战中的大规模使用可参照 Tauri 桌面开发指南 的插件接口设计。

延伸阅读

• 下一篇「Vec 与 HashMap」进入集合实战，泛型与 trait 在那里会反复出现。
• trait 对象的生命周期问题在生命周期一章有铺垫，想深挖虚表机制可以回看。
• 正则表达式精进 的 trait 组合示例展示了如何用小 trait 拼出解析流水线，值得仿写。