• 静态分发（Static Dispatch / impl Trait 或泛型）：
  • 底层机制：编译器在编译期进行单态化（Monomorphization）。它会找出你用这个泛型传入的所有具体类型，为每个类型原样复制并生成一份专属于该类型的机器码。
  • 内存与性能：执行时是直接的函数调用（Direct Call），内联（Inline）优化空间极大，没有任何运行时开销。代价是会导致编译出来的二进制文件体积变大（代码膨胀）。
• 动态分发（Dynamic Dispatch / dyn Trait）：
  • 底层机制：在运行时通过虚表（vtable）查找对应的函数。
  • 内存布局：dyn Trait 在指针层面是一个胖指针（Fat Pointer），占用 2 个机器字长（通常 16 字节）：一个指针指向数据本身（堆或栈上），另一个指针指向该类型专属的虚表（包含析构函数、大小、对齐方式以及 Trait 方法的函数指针）。
  • 性能影响：通过间接调用（Indirect Call）执行，CPU 无法做分支预测和内联优化，运行时会有微小的性能损耗。

// 这是一个非对象安全的 Trait，因为包含泛型方法 `process`
trait Processor {
    fn process<T>(&self, input: T); 
}

struct MyProcessor;
impl Processor for MyProcessor {
    fn process<T>(&self, _input: T) {}
}

fn main() {
    let p = MyProcessor;
    // ❌ 编译报错：无法将该 Trait 转为 Trait Object 动态分发
    let _trait_object: &dyn Processor = &p; 
}

error[E0038]: the trait `Processor` cannot be made into an object
 --> src/main.rs:13:24
   |
13 |     let _trait_object: &dyn Processor = &p;
   |                        ^^^^^^^^^^^^^^ `Processor` cannot be made into an object
   |
note: for a trait to be "object safe" it needs to allow building a vtable
     method `process` has generic type parameters

• 当一个类型 T 实现了 Deref<Target = U> 时，如果编译器发现当前提供的类型是 &T，但函数签名要求的是 &U，编译器就会在编译时自动且无缝地为你插入 .deref() 调用。
• 因为标准库中 impl Deref for String { type Target = str; ... }，所以 &String 在需要时会自动转换为 &str。

use std::ops::Deref;

struct BaseConfig {
    pub max_connections: u32,
}

// 错误的尝试：想让 AppConfig 自动拥有 BaseConfig 的所有属性和方法
struct AppConfig {
    base: BaseConfig,
    pub app_name: String,
}

impl Deref for AppConfig {
    type Target = BaseConfig;
    fn deref(&self) -> &Self::Target {
        &self.base
    }
}

fn main() {
    let config = AppConfig {
        base: BaseConfig { max_connections: 100 },
        app_name: String::from("MyApp"),
    };

    // 隐式调用了 base 的属性，初学者看代码会极其困惑：AppConfig 并没有定义 max_connections 呀？
    println!("Max: {}", config.max_connections); 
}

• 为什么是反模式：代码虽然能跑通，但严重降低了可读性。如果 BaseConfig 后续增加了与 AppConfig 同名的方法，会直接引发方法遮蔽（Shadowing）甚至运行时逻辑混乱。在 Rust 中，应当坚持“组合优于继承”，显式地通过 config.base.max_connections 访问，或者使用显式的 Trait 来做能力抽象。

• 开发库（Library）：需要对错误进行强类型精细化控制。调用你这个库的用户，可能需要通过 match 匹配不同的错误分支来做不同的补救逻辑。因此，库应当定义结构化的 enum 错误类型。
• 开发应用/业务（Application）：业务代码（如 Web 后端、命令行工具）往往充斥着各种各样的错误（数据库报错、网络报错、文件找不到）。你通常不需要针对每种错误写补救逻辑，只需要收集上下文、打印日志或返回统一的友好提示。因此，业务开发需要一种能容纳“万物错误”的容器。

• thiserror（常用于写库）：通过宏帮你极其优雅地实现标准库的 std::error::Error 特质，保留强类型的枚举特征。
• anyhow（常用于写应用）：提供了一个类似 Box<dyn Error> 的动态万能错误容器（anyhow::Error），支持通过 ? 快速抛出并附加上下文信息（context）。

// ❌ 错误做法：在向外暴露的库函数中返回 anyhow::Result
pub fn connect_database(url: &str) -> anyhow::Result<()> {
    if url.is_empty() {
        return Err(anyhow::anyhow!("URL 不能为空"));
    }
    // 其他逻辑...
    Ok(())
}

• 为什么被嫌弃：如果上层调用者（应用层）拿到这个库的错误，想要判断“如果是 URL 为空的错误，我就弹窗提示用户重新输入；如果是网络超时的错误，我就自动重试”。由于你返回的是抹除了具体类型的 anyhow::Result，上层用户无法进行 match 穷举匹配，只能被迫去解析你返回的字符串文本（Error Message String Parsing），这在工程上是极易脆弱且极其危险的反模式。