为何std::distance标准仅要求LegacyInputIterator而非LegacyForwardIterator？

你提到的困惑非常合理：仅输入迭代器（比如std::istreambuf_iterator）没有多遍访问的保证，调用std::distance会直接消耗迭代器指向的元素，导致后续无法再读取这些数据，从实用角度看确实显得反直觉。但C++标准这么设计，主要有以下几个原因：

1. 早期标准的设计定位 #

在C++98最初制定迭代器体系时，std::distance的目标是尽可能通用——只要迭代器能从第一个位置递增到第二个位置，就允许计算两者的距离。当时的标准制定者更倾向于给开发者提供灵活的工具，而非通过严格限制来约束使用场景，哪怕某些场景下使用会带来副作用。

2. 标准的行为前提与用户责任 #

标准明确规定，调用std::distance的前提是：两个迭代器属于同一个序列，且第二个迭代器可以通过递增第一个迭代器到达。如果用户用std::istreambuf_iterator这类仅输入迭代器调用std::distance，导致数据被消耗，这属于用户的使用失误，而非标准库的未定义行为。标准库只负责在前提满足时返回正确结果，不承担阻止用户误用的责任。

比如std::list的迭代器是双向迭代器（属于ForwardIterator的子类），用std::distance只是效率稍低（需要遍历计数），但不会破坏数据；而std::istreambuf_iterator的特性就是单次读取，用户选择用它调用std::distance，就需要接受数据被消耗的后果。

3. 委员会的讨论与兼容性考量 #

在C++标准的演化过程中，确实有过是否收紧std::distance迭代器要求的讨论，但最终没有修改，核心原因是：

• 向后兼容性：修改会破坏大量依赖std::distance处理InputIterator的现有代码；
• 设计哲学：C++始终坚持"信任开发者"的理念，让用户自行判断使用场景的合理性，而非通过强制限制避免误用；
• 替代方案明确：如果需要安全的多遍迭代场景，开发者可以自行选择ForwardIterator及以上类型的迭代器，标准库无需强行限制。

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