std::ranges::views 是惰性计算的核心，返回轻量视图对象而非容器，仅保存迭代器和逻辑，访问时才按需计算；链式调用不立即遍历或复制数据，但多次遍历会重复计算，需谨慎物化。
std::ranges::views 是惰性计算的核心
所有 std::ranges::views（比如 views::filter、views::transform）返回的都不是容器，而是轻量级的“视图对象”，它们不持有数据，只保存迭代器和逻辑，真正访问元素时才按需计算。这意味着链式调用不会立刻遍历或复制数据。
常见错误是误以为 views::filter(...).size() 能快速拿到数量——它可能编译失败（因为多数 view 不支持 size()），或触发完整遍历（若你手动写了 std::ranges::distance）。这违背了“惰性”初衷。
- 只在需要迭代时才触发计算：比如用
for (auto x : v | views::filter(...) | views::transform(...)) - 避免提前求值：别对 view 对象调用
std::vector{v}或std::ranges::to<:vector>(v)</:vector>，除非你明确要物化结果 -
views::take(5)和views::drop(10)是安全的惰性操作；但views::reverse在随机访问迭代器上才高效，否则会强制缓存
管道操作符 | 的左右操作数必须匹配
| 是左结合的，左边必须是 range，右边必须是 view 或可调用对象（满足 viewable_range + view 构造要求）。最常踩的坑是把容器直接写在右边：vec | std::ranges::sort —— 这不行，std::ranges::sort 是算法，不是 view，不能接在管道后。
正确做法是用 views:: 命名空间下的 view 适配器，或者用 std::ranges::to 显式转换后再操作。
立即学习“C++免费学习笔记（深入）”；
- ✅ 正确：
v | views::filter(pred) | views::transform(f) - ❌ 错误：
v | std::ranges::sort（编译失败：no match for ‘operator|’） - ⚠️ 注意：
v | views::common在非 common_range 上会强制 materialize，可能带来意外拷贝
自定义 view 需继承 std::ranges::view_interface
自己写惰性 view 时，如果忘了继承 view_interface，会导致无法参与管道、缺少默认 begin/end、甚至被 std::ranges::range 概念拒绝。
这不是语法糖问题，而是概念约束：C++20 的 view 概念要求类型满足 std::ranges::view_base（通过 view_interface 实现）且可默认构造、可移动。
- 必须公有继承
view_interface<yourview></yourview>，否则your_view | views::take(3)编译不过 - 实现
begin()和end()返回符合iterator概念的类型（通常用std::counted_iterator或自定义迭代器） - 不要在
begin()里做重计算——惰性意味着每次调用都应尽可能廉价；状态应存在 view 成员中，而非临时生成
性能陷阱：多次遍历 view 可能重复计算
view 是惰性的，但也意味着没有缓存。同一个 view 被用于两个 for 循环，或传给 std::ranges::find 后又传给 std::ranges::count，就会执行两次完整逻辑链。这在 views::transform 包裹昂贵函数时尤其危险。
没有运行时机制能自动检测“是否已遍历过”，C++20 的 view 设计哲学就是“不隐藏成本”。你要自己决定是否物化。
- 如果需多次访问，显式转成容器：
auto cached = v | views::filter(...) | std::ranges::to<:vector>()</:vector> -
views::cache1（C++23）能缓存首个元素，但不解决全量重算；C++20 中没有标准缓存 view - 调试时加日志到 transform 函数里，很容易发现重复调用——这是验证惰性是否按预期工作的最直白方式
view 的“惰性”不是魔法，它只是延迟执行 + 零拷贝 + 无预分配；但代价是语义更薄、错误更静默、重复计算更隐蔽。写完管道链，先问一句：这个 view 我会用几次？值不值得物化？
