Rust 通过 特征对象 (dyn Trait) 实现多态性，这依赖于 虚表 在运行时调度方法调用。这些虚表是根据每个实现生成的，并严格包含对应于特征方法的函数指针，建立了不同具体类型之间统一的调用约定。
在特征定义中包含关联常量（const NAME: Type;）会阻止对象安全性，因为常量是编译时构造，在单态化期间解决。与方法不同，常量不占用虚表中的槽，因为它们缺乏统一的运行时表示，通常会进行内联或存储在只读数据区。尝试为这样的特征创建 dyn Trait 将要求特征对象动态携带或引用常量值，这与虚表和类型擦除的架构设计相矛盾。
为了解决这个问题，应该将常量转换为方法（例如，fn name(&self) -> Type）或一个关联类型，如果该值代表一种类型。这种更改将值的检索置于虚表中的函数指针之后，从而恢复对象安全性，同时引入最小的运行时开销。
在为嵌入式 RTOS 构建硬件抽象层时，我们需要一个统一的 注册表 来管理实现 传感器 特征的不同传感器驱动程序。每个驱动程序都需要一个独特的 const DEVICE_ID: u16 进行 I2C 总线寻址，我们最初将其定义为特征中的一个关联常量。
当尝试将异构传感器存储在 Vec<Box<dyn Sensor>> 中时，立即出现障碍，编译器报错称特征违反了对象安全规则。这阻止了注册表需要的动态调度，以通用方式轮询传感器。
我们评估了三种方法。首先，将 DEVICE_ID 转换为方法 fn device_id(&self) -> u16 使 Vec 正常工作，但造成了虚表查找的惩罚，并防止了编译时地址验证。其次，利用泛型注册表 Vec<Box<T>> 其中 T: Sensor 被拒绝，因为它要求同质存储，消除了混合温度和压力传感器的能力。第三，实现一个手动类型擦除的枚举 enum DynSensor { Temp(TempSensor), Press(PressSensor) } 保留了常量，但迫使我们在每个新驱动程序时修改枚举，违反了开放/关闭原则。
我们采用了第一种解决方案，接受了运行时成本以获得灵活性。最终系统通过单一接口成功管理了三十种不同的传感器类型，尽管我们在 crate 的指南中记录了架构权衡，以帮助未来的驱动程序作者。
为什么可以在特征对象中使用关联类型，而关联常量则不可以，尽管两者在每个实现中都是编译时解析的？
关联类型被集成到类型系统标识中。当构造特征对象像 Box<dyn Trait<AssocType = u32>> 时，关联类型成为在创建站点已知的静态类型签名的一部分。虚表 保持有效，因为具体类型（因此关联类型）是固定的。相反，关联常量是值，而不是类型。Rust 缺乏 dyn Trait<CONST = 5> 的语法，虚表不能存储任意数据值——只能存储函数指针——使得常量通过擦除的类型不可访问。
特征上的常量泛型是否允许关联常量与特征对象一起使用，从而使常量成为类型的一部分？
应用常量泛型（例如，trait Trait<const N: usize>）确实会使常量成为类型的一部分，但这排除了异构集合。每个不同的常量值实例化一个不同的特征类型，这意味着 Box<dyn Trait<1>> 和 Box<dyn Trait<2>> 是存储在不同 Vec 容器中的不兼容类型。这种方法牺牲了特征对象使用所需的多态容器能力，因此不适合需要混合实现的注册表。
特征对象中缺乏关联常量如何影响依赖于元数据的工厂注册表或插件系统等模式？
开发人员经常尝试遍历 Vec<Box<dyn Plugin>> 以按关联的 const VERSION: &str 进行过滤，却发现元数据已被擦除。解决方案是将元数据嵌入到包裹结构中，随特征对象一起（例如，struct PluginEntry { meta: Metadata, plugin: Box<dyn Plugin> }）或使用 TypeId 和 Any 向下转换以恢复具体类型并访问其常量。后者需要 'static 边界，并否定了特征对象的抽象优势，强调特征对象故意在运行时动态性上取代了编译时信息。