std::views::transform 是惰性视图适配器，不立即执行映射，仅在解引用时调用 lambda；它不分配内存、不满足 sized_range，与 std::ranges::transform 语义不同，且 lambda 每次解引用均重执行，不缓存结果。
std::views::transform 是惰性映射，它不执行任何计算，只构建一个轻量包装器；真正调用 lambda 是在迭代器解引用（operator*）时发生的。
为什么 views::transform 不会立即执行映射
因为它的返回类型是视图（std::ranges::view），不是容器。它内部只保存原始 range 的迭代器和传入的可调用对象（比如 lambda），不分配内存，也不遍历数据。
- 常见错误：对
transform结果调用std::ranges::size—— 大多数 transform 视图不满足sized_range概念，编译失败 - 更隐蔽的坑：把
transform结果传给需要随机访问的算法（如std::ranges::nth_element），可能触发完整物化或编译报错 - 性能影响：如果 lambda 有副作用（比如打印、修改全局状态），每次
*it都会重新触发——不是“一次映射、多次读取”
views::transform 和 std::ranges::transform 完全不是一回事
前者是视图适配器，后者是就地修改算法。名字相似但语义截然不同，混用会导致编译错误或逻辑错误。
-
views::transform(f)：返回新视图，原数据不动，不修改任何元素 -
std::ranges::transform(first, last, out, f)：将f(*it)写入输出迭代器，必须提供目标位置（比如 vector 的begin()） - 错误写法：
v | std::ranges::transform(f)→ 编译失败，operator|右侧必须是 view 或 view-closure，而std::ranges::transform是函数模板，不是类型
lambda 捕获与生命周期必须手动管理
视图对象本身不延长捕获变量的生命周期。如果 lambda 捕获了局部变量的引用，而视图在函数返回后还被使用，就会出现悬垂引用。
- 安全做法：捕获值（
[x]）或智能指针（[sp = std::make_shared）(42)] - 危险写法：
int x = 10; auto v = rng | views::transform([&x](int n) { return n + x; });→ 若v在x作用域外被遍历，UB - constexpr lambda 可以在编译期参与优化，但仅当捕获为空且函数体支持 consteval（如纯算术）
嵌套 views::transform 不会叠加开销，但调试难度上升
每个 transform 都只是增加一层间接调用，编译器通常能内联简单 lambda；但调试时无法单步进入中间层，且类型名极长（如 transform_view）。
- 推荐：复杂逻辑拆成命名 lambda 或独立函数，避免
views::transform([](auto x) { return f(g(h(x))); })这类嵌套 - 注意：若外层
transform的 lambda 调用了内层视图的begin()，会打破惰性——这是少数会让 transform 提前“拉取”数据的场景 - 调试技巧：用
auto声明中间视图，配合 IDE 类型提示查看实际类型；不要依赖decltype(v)手动写模板参数
最容易被忽略的是：views::transform 的 lambda 在每次 operator* 中都被调用，哪怕你反复解引用同一个迭代器（比如 auto it = begin(v); int a = *it; int b = *it;），两次都会执行 lambda —— 它不缓存结果。需要缓存就得自己用 std::memoize（C++23）或手写 wrapper，不能指望视图自动做。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
