std::ranges::views::transform 本身零开销，但误用会导致隐性性能问题：不可与 std::ranges::transform 混用；lambda 捕获需确保生命周期安全；嵌套 transform 不自动合并；不缓存结果，反复遍历重复执行；不可直接取 size。
std::ranges::views::transform 不是性能瓶颈，但用错方式会让它变成隐形开销放大器。 它本身零分配、零预计算，真正耗时来自 lambda 执行时机、捕获对象访问、以及你是否误把它当容器用。
std::views::transform 和 std::ranges::transform 完全不能混用
看到名字带 transform 就以为能链式调用？错。 std::ranges::transform 是立即执行算法，必须传输出迭代器，返回的是迭代器位置，不是可迭代对象 —— 所以 v | std::ranges::transform(f) 必编译失败，报错 no match for 'operator|'。
正确入口只有两个：
-
data | std::views::transform(f)（推荐，支持后续接views::filter等） -
std::views::transform(data, f)（等价，但链式扩展性差）
手动写 std::ranges::transform_view{data, f} 会因模板推导失败或构造函数不可见而拒绝编译 —— 标准库不提供 public 构造接口。
立即学习“C++免费学习笔记（深入）”；
lambda 捕获生命周期不匹配 = 运行时崩溃
视图不延长任何东西的生命周期，只存引用或拷贝。编译器几乎不报错，但 Release 模式下访问悬垂引用会静默崩坏。
- ❌ 危险：
[&x]{ return x + 1; }中x是局部变量，视图返回后x已析构 - ✅ 安全：
[x]{ return x + 1; }（值捕获），或[&data]{ return data[i]; }（确保data生命周期 ≥ 视图使用期） - ⚠️ 特别注意：函数返回临时
std::vector时，get_data() | views::transform(f)中get_data()在表达式结束即销毁，视图迭代时访问已释放内存
若需动态状态，封装成 functor 类，用成员变量持有资源，并显式控制其生存期。
嵌套 transform 不自动合并，内联依赖编译器和优化级
v | views::transform(f) | views::transform(g) 看似可读，但不等于单次 g(f(x)) 调用 —— 中间适配器对象仍存在，调用栈更深。
- Clang 17+ / GCC 13+ 在
-O2下通常能内联合并 - MSVC 2022 仍可能保留两层适配器开销，尤其当
f或g非 trivial 时 - 更稳做法：
v | views::transform([](auto x) { return g(f(x)); })，减少间接跳转
不要为“语义清晰”牺牲确定性 —— 多一层管道，就多一层未定义行为风险和优化不确定性。
反复遍历 transform 视图 = 反复执行 lambda
它不缓存结果。每次 for (auto x : t) 都重新调用 lambda，且无共享状态。若 lambda 含 IO、锁、或昂贵计算，开销直接翻倍。
- 需要复用结果？必须物化：
std::vector{t}或t | std::ranges::to<:vector>()</:vector> - 想测长度？
std::ranges::distance(t)会完整遍历 —— 若t后接views::filter，代价更高 - 不能调
t.size()—— 它不满足sized_range，编译失败
最易被忽略的一点：你以为在“操作数据”，其实只是在构造一个随时可能失效的计算协议 —— 它的稳定性完全取决于你如何管理源头和 callable 的生命周期。
