std::views::reverse要求底层范围满足ranges::bidirectional_range概念，即迭代器必须支持--操作且正确声明iterator_category；它不修改数据，仅惰性反向遍历，与算法std::reverse语义和行为完全不同。
std::ranges::reverse_view 不会翻转数据，只改变遍历方向；用错容器或忽略生命周期，编译失败或运行时崩溃是大概率事件。
std::views::reverse 编译报错 static_assert failed due to requirement 'ranges::bidirectional_range<v>'
这是最常见也最容易被误判的错误——你以为只是“换个顺序读”，但 std::views::reverse 实际要求底层范围必须满足 ranges::bidirectional_range 概念，即迭代器要支持 --it 操作。
-
std::vector、std::list、std::array、std::string都行 -
std::forward_list、std::istream_view、自定义 range 若没显式声明iterator_category = std::bidirectional_iterator_tag就不行 - 错误不是发生在运行时，而是模板实例化阶段：编译器看到
std::forward_list<int> | std::views::reverse就直接拒掉，不会给你机会调试
std::views::reverse 和 std::reverse 完全不是一回事
名字像，语义天差地别。混淆这两者会导致逻辑错误或性能浪费。
-
std::reverse是算法，接收begin/end迭代器对，真实交换元素位置，O(n) 时间 + 修改原容器 -
std::views::reverse是视图，不碰内存，不拷贝，构造 O(1)，访问时靠反向移动迭代器实现惰性求值 - 只读场景（如日志回溯、UI 渲染最新项在前）必须用
std::views::reverse；若后续还要正向遍历原容器，用它可避免重复拷贝；若必须物理反转数组（比如为后续std::lower_bound做准备），才该选std::reverse
管道链中重建视图比复用更安全
视图不拥有数据，所以生命周期完全依赖原始容器。一旦容器被修改或销毁，已有视图就变成“悬空引用”。
立即学习“C++免费学习笔记（深入）”；
-
std::vector调用push_back、resize或erase后，原有reverse_view的迭代器可能已失效 - 不要写
auto rev = v | std::views::reverse;然后反复用 —— 正确做法是每次需要时重建：for (auto x : v | std::views::reverse) { ... } - 如果链式复杂（比如
v | std::views::filter(...) | std::views::take(5) | std::views::reverse），建议封装成可调用对象：auto rev_filter_take = std::views::filter(pred) | std::views::take(5) | std::views::reverse;，再传入当前v
调试时看不到 reverse_view 内容，别硬猜
IDE（如 VS2022 / CLion）通常不展开 reverse_view 类型，变量窗口里只显示类型名和地址，看不出实际元素。
- 临时观察可用
ranges::to<std::vector>(rev_view)强制 materialize - 想查底层原始范围，调用
rev_view.base()（注意：返回的是正向 view，不是原容器引用） - 空 range 上接
std::views::reverse没问题，但若紧接着接std::views::front就是未定义行为（UB） - 嵌套视图（如 filter + reverse）仍惰性，但每层间接跳转带来微小开销；高频循环里要注意，非关键路径可忽略
真正容易被忽略的点是：reverse_view 对底层 range 的约束不是“看起来能反着走”，而是编译期强制的双向迭代器语义；哪怕你手动写了 --it，没正确设置 iterator_category 或没满足 sentinel_for 关系，照样编译不过。
