std::ranges::transform不是惰性变换且不支持管道操作，因其立即执行、需输出迭代器、返回迭代器而非视图；正确做法是使用std::views::transform构建惰性视图管道。
std::ranges::transform 不是惰性变换，它根本不返回视图；真正做惰性映射的是 std::views::transform —— 混用两者会编译失败、悬垂引用、甚至 Release 下静默崩溃。
为什么 std::ranges::transform 不能用于管道操作
std::ranges::transform 是立即执行的算法，签名要求必须提供输出迭代器（如 std::back_inserter(out)），它不接受单参数 lambda 调用，也不返回可迭代对象。试图写成 v | std::ranges::transform(f) 会触发编译错误：no match for ‘operator|’。
- 传
std::vector<int>{1,2,3}</int>和 lambda 却漏掉输出位置 → 报错：no matching function for call to 'transform' - 即使补上
std::back_inserter(result)，返回值是std::vector<int>::iterator</int>，不是 range，无法继续管道 - 它和
std::views::transform类型系统完全不兼容：前者返回std::ranges::transform_result，后者返回std::ranges::transform_view
如何正确构造 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, [](int x) { return x * 2; }};（极大概率因推导失败或 SFINAE 拒绝） - ⚠️ 注意：
data必须是viewable_range：局部数组、std::vector、std::string都行；但get_data()返回的临时std::vector需先绑定变量，或套std::views::all(get_data())
std::views::transform 的 lambda 捕获与生命周期陷阱
transform_view 内部只保存对 range 和 callable 的引用或拷贝，不延长任何一方生命周期。这是运行时崩溃最高发区，尤其在跨作用域返回或存入全局变量时。
立即学习“C++免费学习笔记（深入）”；
- 用
[&x]捕获局部变量x，但 view 在函数外被遍历 → 悬垂引用，未定义行为 - 原容器是栈上
std::vector<int> data;</int>，却把data | views::transform(f)存入类成员或std::optional→ 迭代时读取已销毁内存 - 安全做法：优先
[=]值捕获；若需移动大对象，显式写[v = std::move(some_thing)]；确保data和 lambda 的生存期覆盖整个 view 使用周期 - 编译器几乎不报这类问题，Release 模式下崩溃才暴露，调试成本极高
别指望 std::views::transform 支持 .size() 或缓存
transform_view 不满足 sized_range，因为转换函数语义不确定（可能返回 std::optional、抛异常、或有副作用），编译器无法静态推断输出长度。
-
v | std::views::transform(f) | std::views::size编译失败 -
std::ranges::distance(v)会强制完整遍历，违背惰性初衷，且若配合filter等视图，可能触发多次计算 - 需要长度？可先转为
common_range：auto t = v | std::views::transform(f) | std::views::common;，再用std::ranges::size(t)（但views::common可能强制拷贝） - 它不缓存结果：每次迭代都重新调用 lambda。若有副作用（日志、IO、随机数），多次遍历会多次触发
最危险的不是写错语法，而是写对了却没意识到 transform_view 里每个引用、每个临时对象、每个 lambda 捕获，都必须活到最后一轮迭代结束 —— 这个约束不会出现在编译期，也不会在 Debug 模式下报错。
