std::views::filter 返回惰性视图而非容器，不可直接当std::vector使用；需显式构造容器或转换；注意谓词捕获安全、原容器修改后旧视图失效、迭代器仅input_category。
std::views::filter 不会立刻筛选出新容器，它只返回一个惰性视图；你不能把它当 std::vector 用，也不能在原容器修改后继续用旧视图。
std::views::filter 返回的不是容器，而是 view 类型
常见错误是写成这样：
std::vector<int> v = {1, 2, 3, 4};
auto filtered = v | std::views::filter([](int x) { return x > 2; });
std::vector<int> result(filtered.begin(), filtered.end()); // ✅ 可行，但绕路
// 或更糟：
some_function_that_takes_vector(filtered); // ❌ 编译失败：filtered 不是 vector这是因为 filtered 的类型类似 std::ranges::filter_view<std::vector<int>&, ...>，嵌套深、不可拷贝（部分情况下）、不兼容容器接口。
- 想转成容器？显式构造：
std::vector<int>(filtered.begin(), filtered.end())或用std::ranges::to<std::vector>（C++23） - 想传给老接口？必须转换，不能强转或 reinterpret_cast
- 链式组合时直接用
|即可，auto能正确推导视图类型
谓词捕获必须安全，且不能有副作用
lambda 捕获局部变量时，若视图寿命超过该变量，迭代时访问就是悬空引用：
立即学习“C++免费学习笔记（深入）”；
auto make_filter_view(int threshold) {
// ❌ 危险：threshold 是栈变量，函数返回后失效
return std::views::filter([threshold](int x) { return x > threshold; });
}正确做法：
- 值捕获没问题：
[threshold]（threshold是int这类 trivial 类型） - 引用捕获仅限生命周期明确的场景，比如捕获类成员或 static 变量
- 避免在谓词里改外部状态（如
count++），因为视图可能被多次遍历、跳过元素、甚至不遍历完 - 谓词参数尽量用
const int&或值类型，避免对const元素调用非常量成员函数
原容器修改后，旧视图必须丢弃重做
这是最容易忽略的运行时陷阱。例如：
std::vector<int> v = {1, 2, 3};
auto view = v | std::views::filter([](int x) { return x % 2 == 0; });
v.push_back(4); // ⚠️ 此时 view 的迭代器已失效
for (int x : view) { /* 未定义行为 */ }原因：视图内部持有原容器的迭代器，而 v.push_back() 可能导致内存重分配，使所有现存迭代器失效。
- 只要修改了底层容器（
push_back、erase、resize等），就不要再用之前创建的视图 - 可以提前把视图管道存为变量复用，但每次要用时都重新绑定到当前容器：
pipeline(v) - 对
std::array或字面量数组，建议用std::span包一层再接filter，避免数组退化为指针丢大小
性能和边界行为：几乎零开销，但最坏情况很“懒”
std::views::filter 自身没有内存分配，每次 ++it 最多调用一次谓词，直到找到下一个匹配项。但它不预计算、不缓存结果。
- 空输入 → 空视图，
begin() == end()，安全 - 全都不满足条件 → 迭代器走到
end()前会反复调用谓词，但不会崩溃 - 谓词抛异常 → 异常在迭代时抛出，不会提前检测，也没办法“跳过”异常元素
- 不支持随机访问：即使原容器是
std::vector，filter_view的迭代器通常只是 input_iterator，不能it += 5
真正复杂的地方不在语法，而在生命周期管理和迭代器有效性——它不报错，但一错就是未定义行为，而且往往只在特定数据路径下才暴露。
