为什么签名相同的Rust闭包不属于同一类型？

这是Rust为了实现零成本抽象做出的主动语言设计选择，既不是类型系统的理论限制，也不是编译器实现的临时妥协。

具体原因说明 #

• 首先要明确Rust闭包的底层实现逻辑：所有闭包在编译期都会被转换成一个独有的匿名结构体，每个闭包对应一个全局唯一的匿名类型，编译器会自动给这个类型实现匹配的Fn/FnMut/FnOnce trait。
  哪怕两个闭包的参数列表、返回值类型完全一致，它们捕获的环境变量、内部逻辑对应的结构体内存布局都可能存在差异，编译器没有任何合理依据将它们合并为同一个类型。举个最直观的例子：

  let offset_a = 10;
  let add_a = |x: i32| x + offset_a;
  let offset_b = 20;
  let add_b = |x: i32| x + offset_b;
  

  这两个闭包签名完全相同，但add_a的匿名结构体内存的是offset_a的相关状态，add_b存的是offset_b的状态，如果强行把两者判定为同一类型，要么会丢失状态信息导致逻辑错误，要么必须引入动态分发、堆分配等额外开销，直接违背Rust零成本抽象的核心设计原则。
• async块的逻辑和闭包完全一致：每个async块在编译期都会被转换成实现了Future trait的匿名状态机，不同async块的await点数量、捕获的环境变量不同，生成的状态机结构、内存布局完全不同，自然不可能归为同一类型。
• 和Haskell的设计差异本质是两门语言的定位和设计目标不同：Haskell作为纯函数式语言，默认所有值不可变，不需要考虑所有权、内存布局、静态分发性能这类系统级问题，它的闭包类型判定只关心输入输出的类型签名匹配，本质是默认做了类型擦除，依赖动态分发运行，和Rust默认优先静态分发、零额外开销的路线完全不同，不存在谁对谁错，只是设计取舍的差异。
• 如果你确实需要把多个同签名闭包作为同类型使用，Rust也提供了明确的手动实现路径：你可以主动将闭包转换为dyn Fn(...) -> .../dyn Future<Output = ...>形式的trait对象，只是这一步带来的动态分发、可能的堆分配开销需要你显式标记，编译器不会隐式帮你做这个转换，避免开发者在不知情的情况下承担非预期的性能损耗。

内容的提问来源于stack exchange，提问作者Test