filter视图必须配合范围适配器链使用，不能单独求值；它惰性过滤、不产生数据，仅返回视图对象，直接取size或构造容器易编译失败或行为未定义。
filter 视图必须配合范围适配器链使用，不能单独求值
std::ranges::views::filter 本身不产生数据，它只返回一个视图对象，内部保存着原始范围和谓词。直接对 filter 结果取 size()、用 std::vector 构造或尝试 auto it = begin(...) 都可能编译失败或行为未定义——除非原范围支持随机访问且谓词不改变迭代器有效性。
常见错误现象：std::vector<int> v = some_range | std::views::filter(pred);</int> 编译不过，因为 std::vector 构造函数不接受视图类型；更隐蔽的问题是，对 filter 视图调用 .size() 时，若底层范围不是 random_access_range 或谓词副作用影响迭代器，结果不可靠。
- 正确做法：始终用
|管道操作符串联，最终接一个消费动作（如std::ranges::for_each、std::ranges::copy或显式构造容器） - 安全落地方式：用
std::ranges::to<:vector></:vector>（C++23）或std::vector{range.begin(), range.end()}（C++20） - 注意谓词签名：必须可调用，参数类型需与范围元素匹配；捕获变量时确保生命周期覆盖整个视图存活期
谓词里修改元素会破坏惰性过滤的语义
filter 视图在每次迭代时才调用谓词，但若谓词内修改了被检查元素（比如 int& x 参数后执行 x *= 2），后续迭代看到的就是已改值——这既违反纯函数预期，也可能导致逻辑错乱（例如本该被过滤的元素因状态变更逃过检查）。
使用场景中容易忽略这点：比如想“边过滤边归一化”，误以为 filter 是处理入口。实际上 filter 只应做判断，不负责副作用。
立即学习“C++免费学习笔记（深入）”；
- 禁止在谓词中修改传入的元素引用或指针所指向内容
- 如需变换+过滤，应先用
std::views::transform，再接std::views::filter，顺序不能颠倒 - 若必须带状态（如计数器），用局部静态变量或外部可变对象时，要意识到 filter 迭代顺序不保证（尤其并行执行时），结果不可预测
filter 后接 views::take 或 views::drop 时，性能取决于底层范围
filter 本身是惰性的，但 std::views::take(5) 要求拿到前 5 个满足条件的元素。如果原始范围很大且符合条件的元素稀疏，filter 可能需要遍历大量元素才能凑够 5 个——这没有额外开销，但开发者容易误判时间复杂度为 O(1) 或 O(5)。
实际性能影响明显：对 std::vector 这类随机访问范围，filter | take 仍是线性扫描；但对输入范围（如 std::istream_iterator），一旦触发求值就不可重放，多次遍历需重新构造视图。
- 避免嵌套多层 filter + take 组合，尤其在循环中反复创建——视图对象轻量，但谓词调用次数可能爆炸
- 若需频繁随机访问筛选结果，先 materialize 到
std::vector更合适，而非反复走视图链 - 编译器无法跨视图优化谓词调用，每个
filter都独立执行自己的谓词，即使逻辑相同
自定义范围与 filter 的兼容性陷阱
如果你写了自定义范围类型，并希望它能和 std::views::filter 一起用，必须满足 std::ranges::range 概念，且其迭代器满足 std::input_iterator（最低要求）或更高概念。否则 | 操作符找不到匹配的 operator| 重载。
常见错误现象：error: no match for operator|，或编译器提示 “constraints not satisfied” —— 多半是迭代器缺少 difference_type、reference 类型别名，或没声明 begin()/end() 成员/自由函数。
- 最简验证方式：用
static_assert(std::ranges::range<myrange>);</myrange>和static_assert(std::input_iterator<:ranges::iterator_t>>);</:ranges::iterator_t> - filter 不关心你是否支持
size()，但若想用views::take或算法如std::ranges::count_if，就需要更多概念支持 - 自定义谓词若依赖 ADL 查找（如重载
operator()在特定命名空间），确保调用点可见，否则 filter 内部可能无法实例化
