为何`FromIterator`的实现使用`IntoIterator`而非`Iterator`？

没错，你的判断完全正确——IntoIterator的要求确实比Iterator更宽松，这正是Rust团队设计这个签名的核心原因之一，同时还有不少实用的设计考量，我来拆解一下：

首先得明确两个trait的定位：

• Iterator是迭代器本身的抽象，要求实现next()方法，代表“能逐个产出元素”的类型。
• IntoIterator是可转换为迭代器的抽象，它的into_iter()方法会返回一个Iterator实现，代表“某个类型可以被转换成迭代器来遍历”。

1. 更宽松的输入范围，减少冗余代码 #

如果from_iter直接要求Iterator，那每次调用时你都得手动把集合转换成迭代器——比如写Vec::from_iter(my_vec.into_iter())。但用IntoIterator的话，你可以直接传集合本身（比如Vec、HashSet这些），Rust会自动调用它们的into_iter()方法，代码更简洁：

let nums = vec![1, 2, 3];
// 直接传Vec，无需手动转迭代器
let new_nums: Vec<i32> = Vec::from_iter(nums);

2. 支持基于引用创建新类型 #

很多集合类型不仅为自身实现了IntoIterator，还为它们的引用（&T、&mut T）实现了这个trait，分别返回引用类型的迭代器。这意味着你可以基于现有集合的引用创建新类型，而不用消耗原集合：

let nums = vec![1, 2, 3];
// 传不可变引用，原nums还能继续使用
let cloned_nums: Vec<i32> = Vec::from_iter(&nums);
println!("原集合还在：{:?}", nums);

3. 和Rust迭代器生态保持一致 #

Rust里的for循环就是基于IntoIterator工作的——for x in collection本质上是把collection转换成迭代器后遍历。FromIterator用同样的抽象，让API风格统一，开发者不用在不同场景下切换思维模式，学习成本更低。

简单来说，IntoIterator相当于给from_iter开了个“便利通道”：不管是迭代器本身，还是能生成迭代器的集合/引用，都能直接传进去，既灵活又符合Rust的设计哲学。

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