临时对象生命周期延至范围for循环结束；但直接取引用、存指针或误用C++20 init-statement易导致悬空；prvalue范围表达式属“真临时”，需警惕非拥有型类型如string_view和ranges视图的内存安全。
临时对象生命周期只撑到循环结束
当你写 for (auto x : getVector())，getVector() 返回的 std::vector 是个临时对象，它的析构时机被 C++ 标准明确延长至整个范围 for 循环语句结束——不是循环体每次迭代结束，而是整个 for 语句块执行完才销毁。
这意味着：只要你不把它的引用/指针存到循环外，基本是安全的；但一旦你做了类似下面的事，就立刻越界：
-
const auto& ref = *begin(getVector());——getVector()的临时对象在表达式求值后立即销毁，ref悬空 -
for (const auto& x : getVector()) { store_ptr(&x); }—— 存的是循环内x的地址，而x是对临时对象元素的引用，临时对象一销毁，所有指针全失效
C++20 init-statement 写法更危险
C++20 允许写成 for (auto v = getVector(); const auto& x : v)，看起来比直接写 getVector() 更可控，但其实埋了两个坑：
-
v是在 init 部分构造的，生命周期覆盖整个循环，**看似安全**；但如果getVector()返回的是移动构造的临时对象，而你又在循环中反复调用v.size()或v.data()，某些实现可能因优化或调试模式差异暴露未定义行为 - 若
getVector()实际返回的是std::vector&&，而v是auto（即std::vector值类型），那会触发一次移动构造——这本身没问题，但如果你误以为v和原对象共享缓冲区（比如用了std::move后还去访问原对象），就会出错 - 最隐蔽的是：当
getVector()内部依赖某个局部静态资源（如缓存、单例句柄），而该资源在v构造后、循环开始前就被释放（例如跨线程或异常路径），v可能变成“合法但无效”的容器
map、string_view 等非拥有型类型要特别小心
像 std::map 的 value_type 是 std::pair<const key value></const>，遍历时 auto& p : m 中的 p 是对节点的引用；但如果你遍历的是 getMap().views::keys() 这类视图（C++20 ranges），它底层可能包装一个指向临时 map 的裸指针——此时 for (const auto& k : getMap() | std::views::keys) 就是典型悬空场景。
立即学习“C++免费学习笔记（深入）”；
同理，std::string_view 本身不拥有所指内存，所以：
-
for (std::string_view sv : getStrings())—— 如果getStrings()返回std::vector<:string></:string>，那没问题；但如果返回std::vector<:string_view></:string_view>，且这些string_view指向的是getStrings()内部临时字符串的内存，那就危险了 - 编译器不会报错，运行时可能表现为随机乱码或崩溃，尤其在 ASan 关闭时极难复现
怎么判断你正在遍历的到底是不是“真临时”
关键看 range_expression 的类型是否为纯右值（prvalue）：
-
{1,2,3}、std::vector{1,2,3}、func()（返回值类型非引用）——都是 prvalue，属于“真临时” -
static_vec、global_array、std::move(existing_vec)—— 后者是 xvalue，生命周期不自动延长，必须靠变量绑定才能延长 - 一个快速验证方法：
auto&& r = range_expression;然后观察r是否能在循环外取data()或size()；如果能且结果合理，说明它不是纯临时，或者已被绑定延长
真正容易被忽略的，是那些看似“只是个函数调用”，实则内部 new 了一块内存、再用 unique_ptr 包一层返回的场景——这种临时对象的生命周期由智能指针管理，和标准规定的临时延长规则无关，得靠你自己确保指针不逃逸。
