std::views::transform 是惰性视图适配器，而 std::ranges::transform 是立即执行的算法；混用会导致编译失败或悬垂引用，且前者不缓存、不管理生命周期、不支持随机访问。
std::ranges::transform 不是惰性变换，它是立即执行的算法；真正实现惰性映射的是 std::views::transform —— 混用两者会导致编译失败或悬垂引用。
std::ranges::transform 和 std::views::transform 完全不是一回事
看到名字带 transform 就下意识想“对每个元素做点什么”，结果传个 lambda 给 std::ranges::transform 却报错 error: no matching function for call to 'transform'，这是最常见误用。
-
std::ranges::transform是算法：必须提供输入 range、输出迭代器（比如std::back_inserter(dest)），立即遍历并写入，不返回视图 -
std::views::transform是视图适配器：只构造轻量对象，不分配内存、不触发计算，返回类型是std::ranges::transform_view - 不能手动写
std::ranges::transform_view{r, f}—— 模板参数推导易失败，且标准库不鼓励直接构造 - 必须用管道符
|或工厂函数：v | std::views::transform(f)或std::views::transform(v, f)
lambda 捕获和生命周期是最大雷区
std::views::transform 内部只保存对 callable 和 range 的引用（或值拷贝），不做生命周期管理。一旦引用的对象提前析构，后续迭代就是未定义行为。
- 错误写法：
auto make_doubler(const std::vector<int>& data) { int factor = 2; return data | std::views::transform([&factor](int x) { return x * factor; }); }</int>→factor是局部变量，返回的 view 引用已销毁内存 - 安全做法：改用值捕获
[=]，或显式移动捕获[factor = std::move(factor)]，或确保被引用对象生命周期覆盖整个 view 使用期 - 对临时 range 更危险：
get_data() | std::views::transform(f)中get_data()返回纯右值，需先绑定到变量或用std::views::all包装
管道中多次使用 transform_view 要小心重复计算
视图是惰性的，但“惰性”不等于“缓存”——每次遍历都会重新调用 lambda，没有 memoization。
立即学习“C++免费学习笔记（深入）”；
- 如果 lambda 有副作用（比如日志、IO、随机数生成），多次迭代会多次触发，行为可能不符合预期
- 若需物化结果（避免重复计算），必须显式转换：
std::vector result{v | std::views::transform(f)}或v | std::views::transform(f) | std::ranges::to<:vector>()</:vector> -
std::views::transform本身不支持.size()或随机访问（除非底层 range 支持且 lambda 是平凡的），别指望它像容器一样查长度
编译器内联决定性能，但类型推导可能卡住你
现代编译器（GCC 13+/Clang 16+）在 O2 下通常能把 v | views::filter(p) | views::transform(f) 内联成接近手写循环的代码，但前提是类型能被干净推导。
- lambda 返回临时对象（如
std::string{"hello"}）可能导致transform_view::reference绑定到临时，触发error: binding reference to temporary - 解决方法：让 lambda 返回值类型明确可绑定，例如用
const std::string&或返回std::string_view（如果源数据支持） - 调试时可用
auto&& x = v | views::transform(f); static_assert(std::ranges::range<decltype>);</decltype>快速验证是否真构成合法 range
最容易被忽略的，是把 views::transform 当成“安全的函数式封装”而放松对生命周期的警惕 —— 它轻量、高效，但也足够危险：编译器几乎不报错，出问题常在运行时，且 Release 模式下更难定位。
