C++20中views管道操作符|只能作用于view或可隐式转换为view的对象，临时容器如std::vector{1,2,3}不能直接参与管道；须先用std::views::all转为view，且filter/transform等返回惰性view，不触发计算，需显式转换为容器才能获取结果。
views 管道操作符 | 必须用在左值或临时 view 上，不能直接对容器调用
常见错误是写 std::vector{1,2,3} | std::views::filter([](int x){return x%2;}) —— 这在 C++20 标准下不合法，因为 std::vector 本身不是 view，且临时对象绑定到 operator| 的左操作数时，要求左侧必须是 view 类型（或能隐式转为 view）。编译器通常报错类似：no match for operator| 或 candidate template ignored。
正确做法是先转成 view：用 std::views::all 或直接用容器的 view 成员（如 vec | std::views::all），再接管道。更简洁的是让容器本身参与 view 构建链的起点：
-
auto v = std::views::iota(0, 5) | std::views::filter([](int x){return x%2;});（纯 view 起点，安全） -
std::vector<int> vec = {1,2,3,4,5}; auto v = vec | std::views::filter([](int x){return x>2;});</int>（C++23 允许，但 C++20 需要std::views::all(vec)） - C++20 中稳妥写法：
auto v = std::views::all(vec) | std::views::filter(...);
filter / transform 等适配器返回的是 lazy view，不触发计算
你写完 auto v = vec | std::views::filter(...) | std::views::transform(...);，此时什么都没执行，内存里只有轻量级迭代器包装器，v 大小甚至可能无法用 v.size() 获取（除非底层 view 支持 sized_range）。这和 std::transform 或 std::copy_if 完全不同——后者立刻分配内存、搬运数据。
这意味着：
立即学习“C++免费学习笔记（深入）”；
- 不能对未支持
sized_range的 view 调用.size()，会编译失败或抛std::bad_optional（取决于实现） - 如果想落地为容器，必须显式转换：
std::vector<int> result(v.begin(), v.end());</int>或用std::ranges::to<:vector>(v)</:vector>（C++23） - 多次遍历同一 view 可能重复触发 predicate（比如 filter 里的 lambda），注意副作用
自定义 range adaptor 需满足 range_adaptor_closure 概念
想写 vec | my::filter_even 这种语法？别直接重载全局 operator|。标准要求自定义适配器必须是可调用对象，且满足 range_adaptor_closure：即它得能“延迟绑定”，把传入的 range 封装进一个 closure 对象里，等真正被管道右侧消费时才构造 view。
典型写法是用 std::ranges::view_closure（C++23）或手动实现 operator() 和 operator|：
struct filter_even_t {
template<std::ranges::input_range R>
constexpr auto operator()(R&& r) const {
return std::forward<R>(r) | std::views::filter([](int x){return x%2==0;});
}
};
inline constexpr filter_even_t filter_even{};
这样 vec | filter_even 才能通过 ADL 正确解析。漏掉 constexpr 或模板约束，容易导致 SFINAE 失败或静默降级为普通函数调用。
views 在 debug 模式下可能因断言失败而崩溃
某些标准库实现（如 libstdc++ 13+、MSVC STL）会在 debug 模式下对 view 迭代器做额外检查：比如访问越界、对已销毁 range 的 view 继续迭代、或用 move 后的 view。现象是触发 __glibcxx_assert 或 STD _DEBUG_ERROR，而不是静默 UB。
排查要点：
- 确认 view 生命周期不短于它的使用者（尤其避免返回局部
std::views::filter给调用方） - 不要对同一个 view 多次调用
begin()后反复++，除非它明确是forward_range（filter不是） - 避免在
transform的 lambda 里捕获悬空引用（比如捕获了已析构容器的元素）
这些坑往往只在 debug build 显现，release 下可能看似正常，但行为不可靠。
