应使用 std::views::transform 而非 std::ranges::transform 实现惰性变换，因后者是立即执行算法、不返回视图，且无法参与管道操作；手动构造 transform_view 易致编译失败或运行时崩溃，需确保捕获对象生命周期安全。
别用 std::ranges::transform 做惰性变换——它根本不是干这个的。真正该用的是 std::views::transform，否则轻则编译失败，重则 Release 模式下静默读取已销毁内存。
为什么 std::ranges::transform 不能接管道符 |
std::ranges::transform 是立即执行的算法，签名要求你提供输出迭代器（比如 std::back_inserter(out)），返回的是一个迭代器位置，不是 view，也不满足 viewable_range 概念。管道操作符 | 的右操作数必须是视图适配器，而它不是。
-
v | std::ranges::transform(f)→ 编译报错：no match for ‘operator|’ -
std::ranges::transform(v, f)（漏掉输出目标）→ 报错：no matching function for call to 'transform' - 即使补上
std::back_inserter(result)，它也立刻遍历、写入、分配内存，彻底失去惰性和链式能力 - 返回类型是
std::ranges::transform_result，无法用于for (auto x : ...)遍历
怎么正确构造 std::views::transform 管道
入口只有两个，且都强制走标准推导路径；手动构造 std::ranges::transform_view 对象是高危行为，99% 的编译失败和运行时崩溃都源于此。
- ✅ 推荐管道风格：
auto v = data | std::views::transform([](int x) { return x * 2; }); - ✅ 函数风格（等价）：
auto v = std::views::transform(data, [](int x) { return x * 2; }); - ❌ 禁止手造：
std::ranges::transform_view{data, [](int x) { return x * 2; }}—— 模板参数推导极易失败，且标准库明确不鼓励 - ⚠️
data必须是viewable_range：局部std::vector、std::array、裸数组都行；但get_data()这类返回临时std::vector的函数，得先写auto tmp = get_data(); auto v = tmp | std::views::transform(f);，或套std::views::all(get_data()) | std::views::transform(f)
lambda 捕获与生命周期：最隐蔽的崩溃源
std::views::transform 内部只保存对 range 和 callable 的引用或拷贝，不延长任何一方生存期。编译器几乎不报错，崩溃常出现在 Release 模式下，调试极难。
立即学习“C++免费学习笔记（深入）”；
- ❌ 危险写法：
[&x]{ return x + 1; }，其中x是栈上局部变量，视图返回后x已析构 → 后续遍历触发悬垂引用 - ❌ 同样危险：
std::vector<int> data{1,2,3}; auto v = data | std::views::transform([&data](int a) { return a * data.size(); });</int>→ 若data离开作用域，v迭代即未定义行为 - ✅ 安全做法：优先值捕获
[=]；对大对象考虑移动捕获[v = std::move(big_obj)]；若需跨作用域持有状态，改用std::shared_ptr或封装为 functor 类并控制其生存期
transform_view 不支持 size() 的真实原因
它不满足 sized_range 概念，因为转换函数语义不确定：可能返回 std::optional<t></t>、抛异常、甚至依赖外部状态。编译器无法静态推断输出长度。
-
v | std::views::transform(f) | std::views::size→ 编译失败 - 想获取数量？只能用
std::ranges::distance(v | std::views::transform(f))，但它会完整遍历，违背惰性初衷，且可能触发多次计算（尤其配合filter时） - 若真需要长度，可先物化：
auto t = v | std::views::transform(f) | std::views::common;，再调用std::ranges::size(t)，但std::views::common可能强制拷贝整个结果
最容易被忽略的点是：所有“看起来像变换”的东西，其实都只是包装；真正执行发生在每次 operator* 调用时。这意味着 lambda 捕获对象、源 range、甚至视图本身，只要有一个提前析构，后续任意一次迭代都可能崩——而且往往只崩在特定优化级别下。
