std::views::filter 必须用管道符 | 链式调用，不可嵌套调用；返回惰性 view，谓词需可拷贝且支持 const 引用调用；捕获局部变量需注意生命周期，推荐值捕获；与 transform 混用时顺序影响语义；调试可用 ranges::to 强制求值。
std::views::filter 本身支持链式调用，但必须用管道操作符 |
直接连续写多个 filter 不会编译通过，比如 vec | filter(p1) | filter(p2) 是合法的，而 filter(filter(vec, p1), p2) 会失败——因为 std::views::filter 返回的是一个 view 类型（如 filter_view），不是容器，不能直接作为第一个参数传给另一个 filter 函数模板。只有管道语法能自动推导适配器链。
关键点：
-
std::views::filter是范围适配器（range adaptor），设计初衷就是配合|使用 - 每个
| filter(pred)都作用于前一个 view 的结果，惰性求值，不产生中间容器 - 谓词
pred必须可拷贝，且对元素类型有 const 引用调用能力（bool pred(const T&)）
链式 filter 中的捕获变量要小心生命周期
如果在 lambda 中捕获局部变量（比如 [x]{ return val > x; }），而该 view 后续被存储或延迟使用，就可能访问已销毁的栈内存。这是常见崩溃源头。
安全做法：
- 优先捕获值（
[x]）而非引用（[&x]），前提是x可拷贝且开销可控 - 若需捕获大对象或动态数据，改用
std::shared_ptr或确保 view 生命周期不超变量作用域 - 避免在函数返回值中返回含栈变量捕获的 view，例如不要写
return vec | filter([x]{...});
和 std::views::transform 混用时注意 view 类型叠加顺序
过滤和转换可以任意组合，但顺序影响逻辑和性能。例如：
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
auto result = data
| std::views::filter([](int x) { return x % 2 == 0; })
| std::views::transform([](int x) { return x * x; })
| std::views::filter([](int x) { return x > 100; });
这等价于“先取偶数、再平方、再筛大于 100 的结果”。如果把最后一个 filter 提前，比如放在 transform 前，语义就变成“只对偶数中大于 10 的做平方”，结果不同。
注意事项：
- 每个适配器都保持原始迭代器 category（如
random_access_range经filter后降为forward_range） -
filter之后接transform没问题；但transform后再filter，谓词作用的是变换后的值，不是原值 - 调试时可用
std::ranges::to<:vector></:vector>强制求值观察中间结果，但仅用于调试，别留在生产逻辑里
编译器和标准库支持差异会影响错误信息可读性
Clang 15+ 和 GCC 13+ 对 range adaptor 链的诊断较友好；MSVC 2022 17.5+ 支持完整 C++20 ranges，但早期版本（如 17.2）对嵌套 filter 的报错常指向内部模板，看不出是漏了 | 还是谓词类型不对。
排查建议：
- 确认编译选项启用了
-std=c++20（GCC/Clang）或/std:c++20（MSVC） - 检查是否遗漏
using namespace std::views;或每次写全std::views::filter - 若用 auto 推导 view 类型，别把它传给期望
std::vector或std::array的函数——view 不隐式转换 - 错误信息里出现
no match for operator|或concept 'range' not satisfied'，大概率是左边操作数不是 view 类型（比如传了std::vector却没加|）
链式 filter 看似简单，真正容易出问题的地方不在语法，而在谓词的求值时机、捕获语义和 view 类型传播——这些不会报编译错误，但会让行为和预期差很远。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
