最直接标准做法是用 std::views::filter 和 std::views::transform 构建惰性视图，避免中间容器分配；lambda 不能捕获，需改用函数对象或传参；链式顺序必须为 filter 在前、transform 在后；转 vector 推荐 C++23 的 std::ranges::to()，C++20 需先 reserve 再 copy；filter_view 不可写，不拥有数据，仅跳过元素。
用 std::ranges::filter_view + std::ranges::transform_view 链式组合最直接
标准做法不是“先过滤再转换成新容器”，而是构建一个惰性视图（view），只在需要时计算。这样避免中间临时 std::vector 分配，也符合 ranges 的设计哲学。
常见错误是试图用 std::ranges::copy 强制立刻求值却忘了目标容器要预先分配空间，或者误以为 transform_view 能直接接受 lambda 捕获——它要求可默认构造，捕获 lambda 不满足这点。
- 必须用
std::views::filter和std::views::transform（C++20 推荐写法，比裸 view 类型更简洁） - lambda 不能带捕获；如需外部变量，改用函数对象或把变量传入 lambda 参数（比如通过
std::bind或闭包外提） - 链式顺序很重要：
vec | std::views::filter(...) | std::views::transform(...)是合法的，反过来则类型不匹配 - 如果最终真要转成
std::vector，得显式调用std::ranges::to<:vector>()</:vector>（C++23）或手动std::ranges::copy到已预留容量的容器
想立刻得到 std::vector？用 std::ranges::to（C++23）或手动 std::ranges::copy
std::ranges::to 是最干净的方案，但仅限 C++23。C++20 用户得自己处理目标容器生命周期和容量——否则 push_back 可能引发多次重分配。
典型错误：对空 std::vector 直接 std::ranges::copy(view, std::back_inserter(vec))，性能差；或用 vec.begin() 却没保证 size 足够，导致越界写。
立即学习“C++免费学习笔记（深入）”；
- C++23：
auto result = view | std::ranges::to<:vector>();</:vector> - C++20：
std::vector<int> result; result.reserve(std::ranges::distance(view)); std::ranges::copy(view, std::back_inserter(result));</int> - 注意
std::ranges::distance对某些 view（如istream_view）是 O(n)，别滥用在未知长度输入上
std::views::filter 的谓词为什么不能修改元素？
因为 filter_view 只读遍历原始 range，它内部存储的是迭代器对，不拥有数据，也不允许通过它间接修改原容器。如果你看到“无法赋值给 filter_view 的元素”，说明误用了 auto& 绑定到 view 的 operator[] 返回值——那其实是 const 引用或 proxy 类型。
- 要修改原容器中符合条件的元素，得先拿到原始迭代器（比如用
std::ranges::find_if或循环原始容器 + 手动判断） -
filter_view的唯一职责是“跳过”某些元素，它不提供写入接口 - 试图对
filter_view::iterator解引用后赋值，编译会失败，错误信息类似assignment of read-only location
性能关键点：避免重复计算和意外拷贝
view 链本身几乎零开销，但一旦嵌套复杂 lambda 或频繁调用 std::ranges::distance，就可能拖慢。更隐蔽的问题是：某些 view（如 transform_view）的迭代器解引用会每次调用 lambda——如果 lambda 有副作用或耗时，就会被反复触发。
- 不要在
transformlambda 里做 IO、锁、或大对象拷贝；如有必要，提前计算好并捕获（但注意前面说的捕获限制） - 避免对同一个 view 多次调用
std::ranges::size或std::ranges::distance，尤其当底层是 forward_range 甚至 input_range 时 - 如果原始数据是
std::vector<t></t>且确定要全量处理，有时传统 for 循环反而更清晰、更容易被编译器优化
真正容易被忽略的是 view 的 lifetime：所有 view 都引用原始 range，一旦原始容器析构，view 迭代就变成悬垂。别把 view 存成类成员，除非你 100% 控制了底层容器的生命周期。
