std::views::filter 是唯一可用的视图适配器，须用管道符 | 或显式构造调用；返回 filter_view 不拥有数据、不支持下标访问、需确保底层容器生命周期和谓词纯度。
std::views::filter 不能直接用 std::ranges::filter 函数调用
编译会失败，因为 std::ranges::filter 不是函数，它只是命名空间占位符；真正可用的是视图适配器 std::views::filter。
必须用管道符 | 或显式构造语法：
-
vec | std::views::filter(pred)✅ 推荐，语义清晰、可链式组合 -
std::views::filter(pred)(vec)✅ 合法但极少用，可读性差 -
std::ranges::filter(vec, pred)❌ 编译报错：no matching function
管道符左右操作数类型必须匹配：左边是 std::ranges::range（如 std::vector、std::array、std::string），右边是视图适配器（如 std::views::filter）。写反了（比如 std::views::filter(p) | vec）会导致类型不匹配，编译失败。
filter 返回的是 view，不是 vector —— 生命周期和访问方式都不同
std::views::filter 返回的是轻量级、不拥有数据的 filter_view，它只保存对原容器的引用或迭代器。这意味着：
立即学习“C++免费学习笔记（深入）”；
- 不能用
v[0]访问：多数情况下编译失败（no operator[]），因为filter_view默认不满足random_access_range - 不能传给需要
std::vector的函数：比如process(std::vector<int>)</int>，必须显式转换：std::vector{v.begin(), v.end()} - 不能返回局部容器的 filter 视图：例如函数内写
return vec | std::views::filter(p);，vec是局部变量，返回后析构，视图立即悬垂 - 避免绑定临时对象的引用：
auto& v = vec | std::views::filter(p);是危险写法，v引用的是临时filter_view，作用域结束即失效
安全做法是用 auto v = ... 值语义持有，或立刻转成容器。
谓词 lambda 捕获和副作用是运行时崩溃高发区
filter 视图在迭代时才调用谓词，而迭代可能多次发生、顺序不确定、甚至被复制。若谓词不纯，极易引发未定义行为。
- 捕获局部变量引用：比如
[&threshold]，但threshold在视图生命周期外销毁 → 解引用悬垂引用，崩溃 - 应改用值捕获：
[threshold]，或把阈值作为参数传入（如封装成函数对象） - 谓词中修改外部状态（如
static int count++）：结果不可预测，因视图可能被复制、多次遍历或提前终止 - 对
std::optional<T>或const char*判空不检查：直接*opt或std::string_view(p)可能触发空指针解引用
推荐谓词写成纯函数：无捕获、无副作用、带防御性检查（如先判 opt.has_value() 再解引用）。
filter + transform 链式后仍不能随机访问，别信直觉
即使原始容器是 std::vector，vec | std::views::filter(p) | std::views::transform(f) 的结果仍是嵌套视图（如 transform_view<filter_view<...>>），它不继承 random_access_iterator 特性。
-
v[0]或v.at(0)几乎一定编译失败 - 想取第一个元素？用
std::ranges::begin(v)+std::ranges::advance，或更稳妥地用std::ranges::find_if/std::ranges::for_each - 只想取前 N 个？接
| std::views::take(N)，再转std::vector，别试图靠下标截断 - 性能上没问题：filter 是惰性的，
take(5)后最多只调用谓词直到找到第 5 个匹配项，不会遍历全部
最易被忽略的一点：视图的“轻量”是双刃剑——它不分配内存，但也意味着你得自己管好底层数据的生命周期、谓词的纯度、以及访问方式是否合法。写完别急着跑，先看类型是不是 filter_view，再想清楚“谁在什么时候访问谁”。
