ranges::view 是只读、惰性求值的 move-only 类型，不可拷贝，须用 auto 接收；管道操作符 | 仅支持 viewable_range 与 view_closure；需确保底层 range 生命周期长于视图，避免悬空引用。
ranges::view 是只读、惰性求值的视图，不是容器
直接用 std::vector 那套思维去“存数据”会踩坑。比如写 auto v = std::vector{1,2,3} | std::views::filter([](int x){return x%2;})，这行代码根本编译不过——std::views::filter 返回的是一个视图类型（如 std::ranges::filter_view），它不拥有数据，也不支持拷贝构造（C++20 中多数视图是 move-only 的）。你得用 auto 推导，或显式声明视图类型，但不能当成 std::vector 用。
常见错误现象：error: use of deleted function 'std::ranges::filter_view<...>::filter_view(const std::ranges::filter_view<...>&)'</...></...>。这是因为试图拷贝一个不可拷贝的视图对象。
- 始终用
auto接收视图链结果（最安全） - 若需多次遍历，必须转成容器：用
std::ranges::to<:vector></:vector>（C++23）或手动构造（C++20 需循环 +push_back） - 视图链本身不执行任何计算，只有在迭代时才逐元素触发谓词和转换
管道操作符 | 的左右操作数有严格类型要求
| 不是通用重载运算符，而是为 std::ranges::viewable_range 和 std::ranges::view 类型专门定制的。左边必须是可视为视图的范围（比如数组、std::vector、std::string，或另一个视图），右边必须是 std::ranges::view_closure（如 std::views::filter、std::views::transform）。
典型翻车点：把普通函数对象或 lambda 直接塞进管道，比如 v | [](int x){return x*2;} —— 这会编译失败，因为 lambda 不是 view_closure。
立即学习“C++免费学习笔记（深入）”；
- 必须用
std::views::transform包一层：v | std::views::transform([](int x){return x*2;}) -
std::views::take、std::views::drop、std::views::reverse等都属于标准 view_closure，可直接管道拼接 - 自定义 view 需继承
std::ranges::view_interface并满足std::ranges::view概念，否则无法参与管道
嵌套管道和临时对象生命周期要小心
写 auto r = vec | std::views::filter(p1) | std::views::transform(f1) | std::views::filter(p2) 看似流畅，但每个中间视图都持有对前一个范围的引用。如果原始 vec 是局部变量且提前析构，而 r 还活着，后续迭代就会访问悬空内存。
错误常发生在函数返回视图时：返回 std::vector<int>{1,2,3} | std::views::filter(...)</int> 是危险的，因为临时 std::vector 在表达式结束就销毁了，视图里存的还是它的引用。
- 确保底层 range 的生命周期 ≥ 视图生命周期；优先用命名变量持有源数据
- 避免返回由临时容器构建的视图；如必须，改用
std::ranges::to<:vector></:vector>（C++23）或先 materialize - 调试时可用
static_assert(std::ranges::view<decltype>);</decltype>确认类型确实是 view，再检查其range_reference_t是否绑定到栈对象
性能关键点：filter + transform 的顺序影响缓存与短路
虽然数学上 filter → transform 和 transform → filter 可能等价，但实际执行中差别很大。例如对大 vector 做 transform（如解析字符串）再 filter（如判断是否非空），会强制处理每一个元素；而先 filter 再 transform，就能跳过被过滤掉的元素，节省 CPU 和内存访问。
更隐蔽的是：某些 view（如 std::views::filter）不提供随机访问，导致后续 operator[] 或 begin() + n 失效；而 std::views::transform 若内部函数无副作用，编译器可能做一定优化，但无法跨 view 边界推理。
- 把计算代价高的操作尽量往后放，把快速判定的
filter放前面 - 避免在
transform中做 I/O、锁、或分配——视图迭代是惰性的，但每次调用都会执行 - 需要随机访问时，别依赖视图链，尽早转成
std::vector或用std::ranges::ref_view显式管理引用
std::ranges::views 不提供 debug 断点钩子，出错时只能靠编译器报错位置反推——这时候看清楚每一级的类型（用 decltype + static_assert）比加日志更有效。 
