应使用 std::views::transform 而非 std::ranges::transform 实现惰性变换，因后者是立即执行的算法，前者才是支持管道操作、延迟求值的视图适配器，且需注意源 range 与 lambda 捕获对象的生命周期安全。
别用 std::ranges::transform 做惰性变换——它根本不是干这个的。你要的是 std::views::transform，混用两者轻则编译失败，重则 Release 模式下静默读取已销毁内存。
std::ranges::transform 为什么不能接管道符 |
因为 std::ranges::transform 是算法，不是视图适配器：operator| 右边必须是能构造 view 的东西，而它返回的是 std::ranges::transform_result（本质是迭代器），类型不匹配。
-
v | std::ranges::transform(f)→ 编译报错：no match for ‘operator|’ -
std::ranges::transform(v, f)→ 编译报错：no matching function for call to 'transform'（缺输出迭代器） - 补上
std::back_inserter(out)后它立刻执行、分配、写入，彻底失去惰性和链式能力
std::views::transform 的两种合法构造方式
标准库只保证通过管道或工厂函数构造的 std::ranges::transform_view 安全可推导；手动构造被明确禁止，极易因模板参数推导失败或访问控制限制崩溃。
- ✅ 推荐管道风格：
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, f}—— 访问受限、推导失败、可能静默崩溃
viewable_range 和临时对象生命周期陷阱
std::views::transform 内部只保存对 range 和 callable 的引用或拷贝，不延长任何一方生存期。一旦源数据或捕获变量提前析构，后续遍历就是未定义行为。
- ❌ 危险：
get_data() | std::views::transform(f)——get_data()返回临时std::vector，表达式结束即销毁 - ✅ 安全写法一：
auto tmp = get_data(); auto v = tmp | std::views::transform(f); - ✅ 安全写法二：
auto v = std::views::all(get_data()) | std::views::transform(f); - ❌ 危险捕获：
[&x]{ return x + 1; }中x是局部变量，函数返回后已析构 - ✅ 安全捕获：
[=](int a) { return a + factor; }（值捕获）或显式移动捕获[v = std::move(some_big_obj)]
transform 视图不支持 size() 的真实原因
std::views::transform 不满足 sized_range 概念，因为 lambda 行为不可静态推断：它可能返回 std::optional、抛异常、甚至返回不同长度的字符串，编译器无法确定输出范围大小。
-
v | std::views::transform(f) | std::views::size→ 编译失败 -
std::ranges::distance(v | std::views::transform(f))→ 会完整遍历，开销大且违背惰性初衷 - 若真需要长度，优先查原 range 大小；或先物化：
auto t = v | std::views::transform(f) | std::views::common;再调std::ranges::size(t)（但std::views::common可能强制拷贝）
最隐蔽的问题往往不在语法，而在生命周期——std::views::transform 构造极快，崩溃却常发生在你完全没预料到的 Release 模式迭代时刻。确保 range 和 lambda 捕获对象的生存期覆盖整个视图使用期，比选哪种写法重要得多。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
