std::views::reverse 要求输入范围满足 ranges::bidirectional_range，即迭代器必须支持 --it；它仅改变遍历方向、不修改数据，与 std::reverse 有本质区别，且生命周期完全依赖底层容器。
std::views::reverse 不会翻转数据，只改变遍历方向；用错容器或忽略生命周期，编译失败或运行时 UB 是大概率事件。
为什么 std::views::reverse 编译报错 static_assert failed due to requirement 'ranges::bidirectional_range'
根本原因是传入的范围不满足 ranges::bidirectional_range 概念——它的迭代器必须支持 --it（前向递减），而不仅是 ++it。
-
std::vector、std::list、std::array、std::string都行 -
std::forward_list、std::istream_view不行：前者只有单向迭代器，后者甚至不保存状态 - 自定义 range 必须显式声明满足
ranges::bidirectional_range，不能只靠提供begin()/end() - 管道链中若上游是
views::filter或views::take，它们本身不要求双向，但组合后喂给views::reverse时，整个结果类型仍需满足双向约束——这取决于底层原始 range 是否双向
std::views::reverse 和 std::reverse 的核心区别在哪
名字像，语义和副作用完全不同。
-
std::reverse是算法：接受一对迭代器，真实交换元素位置，O(n)时间 + 修改原容器 -
std::views::reverse是视图：不碰内存，不拷贝，不交换，仅在begin()/end()调用时返回反向迭代器，构造开销O(1) - 对只读场景（如日志回溯、UI 渲染最新项置顶），
views::reverse更安全；若后续还需正向遍历原数据，它避免了重复拷贝 - 误以为
views::reverse等价于std::reverse并对其调用std::ranges::sort，会导致原容器被意外重排（因为视图迭代器解引用后仍指向原元素）
管道链中使用 std::views::reverse 的实际陷阱
链式写法很简洁，但极易因生命周期或迭代器失效引入未定义行为。
- 视图不拥有数据：
auto rev = vec | std::views::reverse;后，若vec被销毁，再访问rev就是 UB - 容器修改后视图失效：
vec.push_back(42)可能使std::vector重新分配，原有rev内部缓存的迭代器全部失效 - 正确做法是「按需重建」：把适配器管道定义为可调用对象，每次用时传入当前 range，例如
auto rev_take3 = std::views::take(3) | std::views::reverse;，然后调用rev_take3(vec) - 调试时 IDE 通常不展开
reverse_view类型，需手动调用.base()查看底层 range，或用ranges::to<:vector>辅助观察内容
空 range 或嵌套视图下的边界表现
看似无害的操作，在组合或边界条件下容易出问题。
- 空
std::vector上用views::reverse没问题，返回空视图；但紧接着接views::front会触发未定义行为（UB） - 嵌套视图如
v | views::filter(...) | views::reverse仍惰性求值，但每层增加一次函数指针跳转，高频小循环中可观测到微小性能差异 - 若底层 range 是
common_range（如大多数标准容器），reverse_view::size()可直接返回；否则需遍历计数，size()可能退化为O(n) -
reverse_view自身总是满足bidirectional_range和common_range，但不自动继承random_access_range—— 即使底层是std::vector，rev[i]仍是O(1)，但rev.end() - rev.begin()不合法
最常被忽略的是：视图的“轻量”不等于“免维护”，它把生命周期责任完全交还给使用者。一旦容器被移动、销毁或重分配，所有基于它的 reverse_view 实例都得同步更新或重建。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
