先 filter 再 transform 才能真正惰性——每次迭代只对通过过滤的元素调用 transform 的 lambda；若顺序颠倒，transform 会在所有原始元素上执行，哪怕被后续 filter 拒绝，造成冗余计算。
为什么 transform | filter 顺序不能颠倒
管道顺序决定执行逻辑：先 filter 再 transform 才能真正惰性——每次迭代只对通过过滤的元素调用 transform 的 lambda。如果写成 v | views::transform(f) | views::filter(pred)，则 f 会在每个原始元素上都执行一次，哪怕它最终被 pred 拒绝，白白浪费计算。
常见错误是凭直觉把“变换”放前面，尤其当变换逻辑简单、过滤条件复杂时，误以为先变后筛更自然。实际上，views::filter 是个“守门员”，它拦下的元素根本不会传给后续视图的 operator*，所以前置 transform 就成了无谓开销。
如何安全组合 transform 和 filter 的管道链
标准写法就是按需触发顺序排列：
-
v | views::filter(pred) | views::transform(f)✅ 推荐，符合惰性语义 -
views::filter(v, pred) | views::transform(f)✅ 等价，函数式风格起手 -
v | views::transform(f) | views::filter(pred)❌ 不推荐，f 被冗余调用
注意：所有中间结果都是 view 类型，支持继续接 | views::take(10) 或 | views::drop(5)，但不能直接 .size() —— 因为 transform_view 和 filter_view 都不是 sized_range。
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
lambda 捕获在多层管道中怎么不出悬垂
每一层视图都独立保存其可调用对象的副本，所以捕获对象的生命周期必须覆盖整个管道的**最晚使用点**，不只是构造时。
- 若捕获局部变量，必须值捕获（
[x]）或用std::shared_ptr包装后捕获指针 - 禁止引用捕获外部栈变量（
[&x]），哪怕只用于filter，因为视图可能逃逸出作用域 - 若数据来自函数返回值（如
get_data()），先绑定到具名变量再进管道，或用views::all(get_data())延长临时对象寿命
例如：auto data = get_data(); auto result = data | views::filter([&data](int x) { return x —— 这里 <code>[&data] 安全，因为 data 是具名变量且生存期明确。
distance() 很慢？别用它测管道长度
std::ranges::distance(v | views::filter(p) | views::transform(f)) 会强制遍历全部原始元素并逐个判断+变换，时间复杂度 O(n)，且无法提前退出。这不是 bug，是设计使然：惰性视图不承诺提供常数时间大小信息。
- 真要查数量，优先查原范围大小（如
v.size()）再估算上限 - 若必须精确计数且性能敏感，考虑物化到容器：
std::vector res{v | views::filter(p) | views::transform(f)}; - 避免在循环中反复调用
distance()，它每次都会重算
最易忽略的一点：你以为自己只是“看看长度”，但 distance() 已经把整个惰性管道跑了一遍——这和直觉相悖，却是惰性求值最典型的隐式代价。
