std::ranges::views::filter 是 c++20 的惰性视图适配器，不立即执行过滤，仅在迭代时按需判断并产出符合条件元素；区别于传统 filter（如 std::copy_if）会立即分配内存并生成新容器。
std::ranges::views::filter 是什么，和传统 filter 有什么区别
它不是函数，而是一个视图适配器对象，作用是把一个范围（比如 std::vector）包装成一个“惰性过滤后的新范围”。调用它不会立刻遍历、拷贝或修改原容器，只记下过滤条件，等你真正开始迭代时才逐个判断、逐个产出符合条件的元素。
常见错误现象：以为 std::ranges::views::filter 会返回新容器（比如 std::vector），结果赋值给 auto 后发现类型是复杂嵌套视图类型，不能直接传给需要 std::vector 的函数。
使用场景：
- 需要链式处理（比如过滤 + 截取 + 转换）
- 处理大容器但只用前几个满足条件的元素
- 避免中间临时容器分配内存
它依赖 C++20 的概念系统，要求谓词（predicate）可调用且返回能转为 bool 的类型；传入的 range 必须是 input_range，且其迭代器需支持 ++it 和 *it。
立即学习“C++免费学习笔记（深入）”；
怎么写一个可用的 filter 视图
关键点在于：谓词必须捕获完整、生命周期安全，且不能有副作用。因为视图可能被多次遍历（取决于底层 range 类型），也可能被复制。
std::vector<int> v = {1, 2, 3, 4, 5, 6};
auto even_view = v | std::ranges::views::filter([](int x) { return x % 2 == 0; });
// ✅ 正确：lambda 无捕获，状态干净
容易踩的坑：
- 捕获局部变量但视图寿命超过该变量：比如在函数内创建视图并返回，却捕获了函数栈上的
int threshold—— 改用值捕获[threshold]或传入参数 - 谓词里修改外部状态（如递增计数器）：结果不可预测，因为视图迭代顺序和次数不保证
- 误用非 const 成员函数做谓词：若 range 元素是 const，而 lambda 尝试调用非常量成员函数，编译失败
filter 视图的迭代性能和边界行为
它本身几乎零开销：没有额外内存分配，每次 ++it 最多检查一次谓词，直到找到下一个匹配项。但最坏情况（比如全都不匹配）可能导致大量谓词调用却无产出。
几个关键行为：
- 空 range 输入 → 空视图输出，
begin() == end() - 谓词抛异常 → 迭代时抛出，不提前检测
- 原 range 被修改（如
vector.push_back()）→ 视图行为未定义（除非是std::span这类不拥有数据的 view） - 对
std::array或字面量数组使用时，注意数组退化为指针会丢失大小信息，建议显式用std::ranges::subrange或std::span
兼容性注意：GCC 10+、Clang 13+、MSVC 19.30+ 支持完整 std::ranges::views::filter；早期版本可能只支持 std::views::filter（需包含 <ranges></ranges> 且开启 C++20）。
什么时候不该用 filter 视图
当你要的是一次性、确定大小、可随机访问的结果，比如后续要反复按索引查第 5 个偶数，或传给只接受 std::vector 的旧接口 —— 这时候直接用 std::copy_if 或 range-based for 手动收集更直白、更可控。
另一个典型陷阱：嵌套 filter 导致可读性骤降，例如
v | views::filter(p1) | views::filter(p2) | views::filter(p3)
不如合并成一个谓词：[](int x) { return p1(x) && p2(x) && p3(x); } —— 更高效，也避免三次惰性跳过逻辑叠加。
视图的“惰性”不是免费的，它把计算时机推迟到了迭代时刻，而那个时刻的上下文（比如变量是否还活着、容器是否被挪走）得你自己兜底。
