自定义Add实现中trait bound检查溢出错误排查

问题背景 #

在开发编译时单位校验的零成本抽象库时，通过SameUnit trait合并两个单位的分子/分母列表来校验单位一致性，却触发了类型检查器的递归溢出错误，核心场景是对相同单位的QuantifiedValue执行加法操作时失败。

溢出原因拆解 #

1. 类型级合并的无限递归隐患 #

你的SameUnit实现依赖Merged关联类型合并列表，再通过SameSuList校验合并结果是否一致。问题出在**Merged的递归逻辑没有正确终止**：

• 以Metre为例，它的ComposedUnitNumerator是Cons<Metre, Nil>，ComposedUnitDenominator是Nil
• 校验(Metre, Metre)时，需要合并U1分子 + U2分母（即Cons<Metre, Nil> + Nil）和U2分子 + U1分母（即Cons<Metre, Nil> + Nil）
• 如果Merged的实现没有处理Nil作为其中一个参数的终止逻辑（比如Nil::Merged<T>没有直接返回T，而是继续触发递归），会导致类型检查器不断展开嵌套的Cons列表，直到超过递归上限。

2. Rust类型检查器的递归限制 #

Rust默认的类型检查递归深度限制为128。当关联类型的递归展开没有明确终止条件时，类型检查器会持续尝试展开类型，直到触发E0275溢出错误。即使你的逻辑最终能收敛到Nil，如果中间展开步骤过多，也会触发这个限制。

3. 冗余的合并逻辑放大问题 #

实际上校验两个单位是否相同，不需要通过合并分子分母的方式——直接分别校验两个单位的分子列表、分母列表是否完全一致即可。当前的合并逻辑额外引入了一层递归，进一步增加了类型检查的负担，放大了溢出风险。

验证与修复方向 #

验证点 #

• 检查Nil的Merged实现：确认Nil::Merged<TList>直接返回TList，而非继续递归
• 检查标准单位的关联类型：确认Metre的ComposedUnitNumerator是Cons<Metre, Nil>，ComposedUnitDenominator是Nil
• 检查SameSuList的终止条件：确认(Nil, Nil)已正确实现该trait

修复方案 #

方案1：优化SameUnit的校验逻辑（推荐）

去掉冗余的列表合并，直接校验分子、分母列表分别相同：

impl<U1, U2> SameUnit for (U1, U2)
where 
    U1: crate::Unit,
    U2: crate::Unit,
    U1::ComposedUnitNumerator: crate::list::SameSuList<U2::ComposedUnitNumerator>,
    U1::ComposedUnitDenominator: crate::list::SameSuList<U2::ComposedUnitDenominator>,
{}

这种方式避免了合并操作的递归，直接聚焦于单位的核心组成校验，效率更高且不会触发溢出。

方案2：修复Merged的终止逻辑

确保Nil作为列表一端时，合并操作直接终止：

impl StandardUnitList for Nil {
    type Merged<TList: StandardUnitList> = TList;
    // 其他关联类型/方法...
}

这样合并Cons<Metre, Nil>和Nil会直接返回Cons<Metre, Nil>，不会产生额外的递归展开。

方案3：临时提高递归限制（不推荐）

在crate根目录添加#![recursion_limit = "256"]可以临时绕过错误，但这只是治标不治本，无法解决递归逻辑的根本问题。

内容的提问来源于stack exchange，提问作者LucioleMaléfique