ranges::filter 并非自动更安全，但能避免索引越界和迭代器失效，通过分离遍历与业务逻辑将错误集中于谓词；其返回只读视图，不拷贝数据，要求谓词纯、不可直接调用.size()，且需注意生命周期与混用限制。
ranges::filter 是不是比 for 循环更安全？
不是自动更安全，但能避免常见索引越界和迭代器失效问题。它把“遍历逻辑”和“业务逻辑”剥离开，错误集中在谓词函数里，而不是散落在循环体中。
-
ranges::filter返回的是一个视图（view），不拷贝数据，也不修改原容器；误用std::vector::erase或手写for (auto it = v.begin(); ...)时容易在遍历时删除元素导致迭代器失效 - 谓词函数必须是纯的（无副作用），否则多次遍历结果可能不一致——比如在 lambda 里修改外部变量，
ranges::filter可能因懒求值被调用多次 - 不能直接对
ranges::filter结果调用.size()（除非加| views::common），因为很多视图不支持 O(1) 长度计算
为什么 ranges::sort(v | views::filter(...)) 编译不过？
因为 views::filter 产生的视图默认是只读的（std::ranges::view 满足 std::ranges::input_range，但不一定满足 std::ranges::random_access_range 或可写要求），而 ranges::sort 要求可写且支持随机访问。
- 正确做法是先 materialize：用
std::vector构造新容器，再排序：auto filtered = v | views::filter(pred) | to_vector();
ranges::sort(filtered); - 如果只是想取 top-K，用
views::take+ranges::partial_sort_copy更高效，避免全量过滤再排序 - C++23 的
to适配器（如| to<:vector>）比to_vector()更通用，但需确认编译器支持（GCC 13+ / Clang 16+）
ranges 和传统 STL 算法混用会出什么问题？
主要出在迭代器类别不匹配和生命周期管理上。范围库的视图对象是轻量、非拥有的，一旦源容器析构，视图立刻 dangling。
- 别把
views::transform的结果传给std::find_if——前者返回transform_view，后者期望传统迭代器对，类型不兼容，编译失败 - 可以混用，但得显式转换：用
ranges::begin()/ranges::end()获取视图的迭代器，再喂给老算法（前提是视图支持对应操作） - 最危险的是捕获局部容器到 lambda 里再进
views::filter：若视图被存储到函数外，容器已销毁，后续访问就是未定义行为
ranges::views::iota(1, 10) 为什么不能直接 push_back 到 vector？
因为 iota 生成的是一个输入范围（input range），其迭代器只能单次遍历，且不支持 push_back 这种容器操作——视图不是容器，它没有内存所有权。
立即学习“C++免费学习笔记（深入）”；
- 要转成容器，必须用
to_vector()、to_deque()或 C++23 的| to<:vector> -
iota在需要数值序列时很简洁，但别把它当std::vector用；想反复遍历，就得 materialize 一次 - 性能上，
iota视图本身几乎零开销，但每次遍历都会重新计算值（比如iota(0, n)中第 i 项是 i），所以对大范围做多次ranges::count_if不如预生成 vector 快
