应使用 std::views::transform 实现惰性变换，std::ranges::transform 是立即执行算法，不可管道操作；手动构造 transform_view 易出错，需注意 lambda 捕获生命周期、无缓存、不支持 size() 等特性。
别用 std::ranges::transform 做惰性变换 —— 它根本不是干这个的。真正该用的是 std::views::transform，否则轻则编译失败，重则运行时读取已销毁内存。
为什么 std::ranges::transform 不能接管道符 |
std::ranges::transform 是算法，不是视图适配器；它要求你提供输出迭代器（比如 std::back_inserter(out)），立即遍历并写入，返回的是一个迭代器位置，不是可管道操作的对象。
- 写
v | std::ranges::transform(f)→ 编译报错：no match for ‘operator|’ - 漏掉输出目标直接调用
std::ranges::transform(v, f)→ 报错：no matching function for call to 'transform' - 即使补上
std::back_inserter，也得不到惰性行为：数据立刻被计算、复制、存储，无法链式组合
std::views::transform 必须走管道或工厂函数
手动构造 std::ranges::transform_view 实例是高危操作：模板参数推导受限、lambda 类型可能不可复制、访问控制可能拒绝，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；若来自临时对象（如get_data()），先绑定变量或套std::views::all(get_data())
lambda 捕获和生命周期是最大隐形陷阱
transform_view 内部只保存对 range 和 callable 的引用或拷贝，不延长任何一方生命周期。一旦引用悬垂，迭代时就是未定义行为，且 Release 模式下极难调试。
立即学习“C++免费学习笔记（深入）”；
- ❌ 危险：
[&x]{ return x + 1; }中x是局部变量，函数返回后即析构 - ❌ 危险：栈上
std::vector<int> v{1,2,3};</int>，却把v | views::transform(f)存进全局std::optional - ✅ 安全：优先值捕获
[=]；大对象需移动时显式写[v = std::move(some_thing)] - ✅ 安全：用
static、类成员、std::shared_ptr或传入副本确保生存期覆盖整个 view 使用周期
transform_view 不缓存、不支持 .size()、不防重复计算
它只在每次 operator* 被调用时执行 lambda，没有 memoization，也没有静态长度信息。你以为“构造完就 ready”，其实连第一个元素都没算过。
- 调用
v.size()→ 编译失败（多数transform_view不满足sized_range） - 想获取长度？
std::ranges::distance(v)会强制完整遍历，违背惰性初衷 - 反复遍历同一视图（如两次
for (auto x : v)）→ lambda 被重复执行，副作用（日志、IO、随机数）会触发多次 - 真要复用结果？必须显式物化：
std::vector result{v | std::views::transform(f)}或v | std::views::transform(f) | std::ranges::to<:vector>()</:vector>
最常被忽略的一点：所有这些陷阱在 Debug 模式下几乎不报错，而 Release 模式优化后，临时对象绑定失效、内联展开、寄存器重用会让悬垂引用崩溃得毫无征兆 —— 别等上线才排查。
