解读

面试官问“默认实现与覆盖的规则”时，并不是想听你背语法，而是想确认你能否在真实工程里：

1. 用 trait 提供向后兼容的扩展点；
2. 知道什么能覆盖、什么不能覆盖，避免写出“编译过了，运行时却 silently 用了默认实现”的坑；
3. 在对象安全（object safety）、泛型特化（specialization）、ABI 稳定性这些国内大厂（华为、阿里、字节、蚂蚁）高频场景里，给出可落地的权衡方案。

一句话：既要写得爽，又要保证后续迭代不翻车。

知识点

1. 默认实现（provided method）
   trait 内带方法体：fn foo(&self) { ... }
   对实现者来说是可选覆盖，对调用者来说是静态分派（monomorphization 阶段就内联掉，零成本抽象）。

2. 覆盖（override）规则
   a. 名字+签名完全一致才能覆盖；泛型参数、where 子句不同即视为重载（overload），Rust 没有重载，会直接编译失败。
   b. 不允许缩小可见性；默认实现是 pub，实现者不能改成 pub(crate)。
   c. 不允许把 &self 改成 &mut self 或反之，否则是不同类型。
   d. trait 继承链中，最底层实现优先级最高；**孤儿规则（orphan rule）**保证只有一方能 impl，避免二义性。
   e. object safety 限制：带泛型参数或 Self: Sized 的默认方法，无法在 trait object 上调用，但覆盖掉后可以（把签名改成不用泛型即可）。

3. 特化（min_specialization / nightly specialization）
   稳定版只允许**“更具体的 impl 覆盖泛型 impl”，且必须加 default impl 标记；stable 上不能玩“同名方法同时存在”，否则 ABI 不稳定，国内做动态库（so/dylib）**时会直接挂。

4. 与 async 的交互
   trait 里写 async fn 目前仍需 async-trait 宏，宏展开的默认实现是 Box<dyn Future>，覆盖时签名必须完全一致（包括 Send 边界），否则 Future 不会自动 Send，在字节、阿里做高并发网关时会导致任务无法 spawn 到 tokio 运行时。

5. 常见踩坑

   • 把默认实现当“虚函数”用，结果trait object 忘了加 dyn，编译器直接报错 E0038。
   • 在no_std 嵌入式场景里，默认实现里用了 alloc::vec::Vec，导致二进制膨胀；覆盖时改成数组即可省 20 KB，华为鸿蒙内核面试常问。
   • 做区块链 runtime（Substrate）时，pallet 的 trait 默认实现改了 StorageItem 名字，链上升級（runtime upgrade）后存储 key 对不上，直接分叉；必须覆盖并显式指定 storage_prefix。

答案

“Rust 的默认实现与覆盖规则可以总结为三句话：

1. 签名完全一致才能覆盖，否则编译器认为是新方法，旧方法依旧存在，导致静默执行默认逻辑——这是线上 P0 故障的最大来源；
2. 覆盖是静态分派，零成本，但 trait object 只能调用 object-safe 的方法，想给 trait object 用就必须把泛型或 Self: Sized 的默认方法覆盖掉；
3. stable 上没有真正的‘重载’，特化实验功能只能在 nightly 玩，国内做动态库或 FFI 时必须保证 impl 唯一，否则 ABI 版本升级会踩坑。

实战建议：先写最小默认实现，只依赖核心 trait 类型参数；需要性能或 no_std 时，再在具体类型上精确覆盖，并用 #[inline] 提示编译器内联，这样既能向后兼容，又能在鸿蒙、蚂蚁链这类场景里通过 128 MB 内存的嵌入式验收。”

拓展思考

1. 如果你给嵌入式 HAL 写 trait，默认实现里用了 f32::sin()，覆盖时如何确保单精度浮点指令不被编译器降级成软浮点？（提示：用 #[inline(always)] + core::intrinsics 强制调用硬件指令，华为海思面试会深挖）

2. 在云原生 sidecar 场景，trait 默认实现里打了一条 tracing::info!，覆盖时想完全去掉日志以减少 syscall，但下游团队已通过 trait object 动态调用，如何既删掉日志又保证 ABI 兼容？（提示：用 #[cfg(feature = "tracing")] 条件编译，阿里 ServiceMesh 组实际做法）

3. 如果未来 Rust 稳定了 specialization，你是否敢在区块链 runtime 里用“泛型 impl + 具体 impl”做优化？存储布局（storage layout）会不会因为 impl 切换而改变？（提示：Substrate 的 StorageHasher 一旦上链就不可变，必须覆盖并显式指定新 hasher，否则分叉；这是蚂蚁链 2023 年真实故障案例）

把这三个问题想透，默认实现与覆盖就不再是语法题，而是架构设计题，面试里就能从“背规则”跃迁到“带方案”，直接拿到 Rust 底层岗的 SP offer。