std::views::filter 和 std::views::transform 必须用 | 串联，不能嵌套调用；| 是核心机制而非语法糖，支持懒求值链式组合，顺序影响语义与性能，view 不拥有数据需注意生命周期。
std::views::filter 和 std::views::transform 必须用 | 串联，不能用函数调用嵌套
管道操作符 | 不是语法糖，而是 C++20 ranges 的核心机制——它把一个 range 和一个 view 适配器连接起来，返回一个新的 view。直接写 views::transform(views::filter(v, pred), fn) 会编译失败，因为 views::filter 返回的是 view 类型（如 filter_view），而 views::transform 期望接收一个 range，不是 view 类型的参数（C++20 中二者虽常兼容，但函数式调用不触发 ADL 查找，且语义模糊）。
正确写法只有一种：v | views::filter(pred) | views::transform(fn)。这个链式结构由重载的 operator| 支持，底层依赖 viewable_range 约束和 ADL 可见的适配器实现。
-
views::filter和views::transform都是“懒适配器”，它们不立刻执行，只构造描述逻辑的 view 对象 - 每个
|操作都产生新 view，前一个 view 的begin()/end()被后一个适配器封装 - 整个链最终必须被“消费”（比如 range-for、
std::ranges::copy或转容器），否则什么都不会发生
顺序错了结果就错：filter 和 transform 的位置影响语义和性能
先 filter 再 transform 是常见需求，但反过来也可能合理——关键看你要处理的是原始值还是变换后的值。比如：
-
v | views::filter([](int x){ return x > 0; }) | views::transform([](int x){ return x * x; })：筛选正数，再平方 -
v | views::transform([](int x){ return x * x; }) | views::filter([](int x){ return x > 10; })：先全平方，再筛大于 10 的结果
两者逻辑不同，输出也不同。更隐蔽的问题是性能：如果 transform 计算代价高（比如字符串解析、浮点运算），而你本可以先用 filter 排除大量无效输入，那把 transform 放前面就是浪费 CPU。
立即学习“C++免费学习笔记（深入）”；
另一个典型陷阱是 views::take 的位置：v | views::take(100) | views::filter(pred) 只在前 100 个元素里过滤；而 v | views::filter(pred) | views::take(100) 才是“取前 100 个匹配项”——顺序一换，语义完全跑偏。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
为什么 auto result = v | filter | transform 后不能直接 result[0] 或 result.size()？
因为 result 是一个 view，不是容器。它不支持随机访问（除非上游 range 本身支持且所有中间 view 保持了该属性，比如 views::reverse 在 vector 上仍可随机访问，但 views::filter 一定破坏随机访问能力）。
-
result[0]编译失败：filter_view 没有operator[] -
result.size()编译失败：大多数 view 不提供size()，因为惰性求值下长度无法静态确定（例如views::generate+filter） - 想取第一个匹配项？用
if (auto it = ranges::find_if(result, [](auto){return true;}); it != result.end()) { ... }，或更简单：for (auto x : result) { use(x); break; } - 想转成 vector？C++20 下需
std::vector<int> out; ranges::copy(result, std::back_inserter(out));</int>；C++23 才支持std::vector<int> out{result}</int>
视图生命周期管理不当会导致悬垂引用
view 不拥有数据，只持有对原始 range 的引用（通常是迭代器或指针）。如果你写：
auto make_even_squares(const std::vector<int>& v) {
return v | std::views::filter([](int n){ return n % 2 == 0; })
| std::views::transform([](int n){ return n * n; });
}然后在外面调用：auto vs = make_even_squares(vec); for (int x : vs) {...} —— 这没问题，因为 v 是 const 引用，生命周期由调用方控制。
但如果你不小心传入临时对象：
auto vs = std::vector{1,2,3,4} | views::filter(...); // 错！
for (int x : vs) { ... } // UB：vector 已析构，vs 持有悬垂迭代器这类错误不会报编译错误，但运行时行为未定义。解决办法只有两个：
- 确保 view 的源 range 生命周期长于 view 本身（最稳妥）
- 需要脱离源生命周期时，立即消费 view 并存入容器（如
std::vector或std::deque）
尤其注意 istream_view、generate 这类不依赖外部存储的 view 是安全的，但凡涉及容器迭代器的 view，都得盯紧生命周期。
