反向迭代器正确实现的关键是operator!=基于逻辑位置而非底层指针比较，需统一转换为base()-1再比较；过滤迭代器须惰性推进且确保operator*前已就位；类型特征须显式定义，禁用std::iterator；range-for崩溃多因begin/end类型不一致或operator!=隐式改变状态。
反向迭代器怎么写才不崩在 operator!=
标准库的 std::reverse_iterator 能用，但自己实现时最容易栽在比较逻辑上：把 operator!= 写成直接比较底层迭代器，结果遍历到末尾就跳过最后一个元素，或者越界访问。
关键不是“反着走”，而是“反着定义边界”。底层迭代器指向的是原容器的后继位置（比如 end()），而反向迭代器的 operator* 应该解引用它前一个位置——所以 operator!= 必须基于「当前反向迭代器所代表的逻辑位置」来比，而不是底层指针值。
- 用一个成员变量存「当前逻辑指向的元素地址」，而非原始迭代器位置；或者更稳妥地，只存原始迭代器，并在
operator!=里统一转成逻辑位置再比（比如base() - 1 != other.base() - 1） - 不要重载
operator==却漏掉operator!=，C++20 前两者不自动互推 - 注意
begin()和end()对应的反向迭代器：前者应由原end()构造，后者由原begin()构造
过滤迭代器如何避免多次调用谓词
每次 operator++ 都重新跑一遍 pred(*it) 看是否跳过？那遇上计算密集型谓词或带副作用的函数（比如日志打印），性能会断崖式下跌，而且行为不可预测。
正确做法是「惰性推进」：构造时只存原始迭代器和谓词，operator++ 里循环跳过不满足的元素，直到停在第一个匹配项或抵达末尾。这样谓词只在真正需要判断下一个有效位置时才调用。
立即学习“C++免费学习笔记（深入）”；
- 必须在
operator*和operator->前确保当前迭代器已停在有效元素上（即提前推进完） - 如果谓词抛异常，得保证迭代器状态仍可读（比如推进前先备份，失败则还原）
- 别在
operator!=里隐式推进——这会让 for-range 循环行为失控
std::iterator 已弃用，新代码怎么标类型特征
C++17 起 std::iterator 被标记为 deprecated，直接继承它会导致编译警告；C++20 彻底移除。但不标类型特征（如 value_type、iterator_category）的话，算法如 std::distance 或 std::sort 可能无法识别你的迭代器。
现在必须显式定义嵌套类型别名，且推荐用 using 而非 typedef，保持与标准库一致风格。
- 至少提供
value_type、difference_type、pointer、reference、iterator_category -
iterator_category别硬写std::forward_iterator_tag：过滤迭代器通常只是input_iterator_tag（因为不能多遍遍历） - 反向迭代器若底层支持随机访问，才用
std::random_access_iterator_tag；否则降级为bidirectional_iterator_tag
为什么自定义适配器常在 range-for 里崩溃
常见原因是 begin() / end() 返回的迭代器类型不一致，或者 end() 迭代器没正确实现「哨兵语义」。range-for 编译成 for (auto it = begin(); it != end(); ++it)，只要 != 行为和 ++ 不匹配，就可能无限循环或越界。
尤其过滤迭代器：如果 end() 返回的是一个「空哨兵」对象（不含原始迭代器），而 operator!= 却试图解引用它，就会 UB。
- 确保
begin()和end()返回同一种迭代器类型（哪怕end()是特化构造） - 避免在
operator!=里做任何可能改变状态的操作（如推进、解引用） - 测试时用空容器、单元素容器、全过滤掉的容器三类边界 case，别只测正常数据
最难缠的其实是移动语义和 const 正确性——一旦迭代器里存了右值引用或裸指针，复制/移动后原对象析构，后续解引用就静默崩溃。这点容易被忽略，但改起来要动整个所有权模型。
