std::views::filter仅构建惰性过滤视图，不立即执行过滤；它返回filter_view对象，持原始范围引用和谓词，所有判断延迟至迭代器解引用时按需进行。
views::filter 本身不执行过滤，只构建过滤视图
调用 std::views::filter 不会立刻遍历原始范围、也不生成新容器。它返回一个轻量级的 filter_view 对象，内部仅保存原始范围的引用和谓词（predicate）——所有计算推迟到迭代时才发生。
这意味着：传入一个耗时函数或副作用逻辑（比如 [&](int x) { std::cout ），你只会看到输出在真正取值时出现，比如用 <code>for 循环或 std::ranges::begin() 触发迭代器解引用时。
迭代器解引用时才逐个调用谓词判断
filter_view::iterator 的 operator* 和 operator++ 协同工作：每次 ++ 都会跳过不满足条件的元素，直到找到下一个匹配项；而 * 只返回该匹配项的引用。这个“跳过”过程就是谓词的实际调用点。
关键细节：
立即学习“C++免费学习笔记（深入）”；
- 谓词可能被多次调用同一元素（比如反复
--it后再++it，取决于迭代器类别，但filter_view的前向迭代器保证每个元素最多被检查一次 per pass） - 如果谓词抛异常，过滤过程立即中止，异常向上抛出
- 原始范围必须保持有效——
filter_view不拷贝数据，只持引用或包装器
和 vector::erase_if 或 copy_if 的本质区别
常见误解是把 views::filter 当成“更快的 std::copy_if”。其实它根本不分配内存、不移动元素、不修改源数据。它只是“看得到的窗口”，而 std::erase_if 或 std::copy_if 是“实际搬运/删除”的动作。
典型误用场景：
- 想“原地过滤
std::vector”却写了v | views::filter(...)—— 这不会改变v，后续仍需std::vector构造或assign才能落地 - 对临时范围（如
std::views::iota(0,100) | views::filter(...)）反复遍历 —— 每次都重新从头跑谓词，没有缓存 - 捕获局部变量进谓词，但
filter_view生命周期长于该变量 —— 导致悬垂引用，UB
调试惰性行为：用断点或日志确认触发时机
最直接验证方式是在谓词里加 std::cout 或断点。例如：
auto r = std::views::iota(0, 5) | std::views::filter([](int x) {
std::cout << "evaluating " << x << '\n';
return x % 2 == 0;
});
// 此时无任何输出
auto it = r.begin(); // 输出 evaluating 0 → match → stop
++it; // 输出 evaluating 1 → skip, evaluating 2 → match
注意：C++23 起 filter_view 要求谓词是纯函数（否则行为未定义），但编译器不强制检查。实际开发中，避免在谓词里做 I/O、修改外部状态或依赖可变全局，否则结果不可预测。
惰性不是魔法，是延迟 + 按需。真正复杂的地方在于：你得自己管好原始数据生命周期、谓词副作用边界、以及什么时候才真正需要“物化”结果。
