c++oding="utf-8" ?>
NRVO仅对单一、具名、非参数的局部对象生效；必须返回函数内定义的非引用/非指针局部变量，且不能是参数或经std::move/类型转换/三元运算符等修饰，C++17强制RVO但NRVO仍为可选优化。
NRVO只对“单一、具名、非参数”的局部对象生效
NRVO不是编译器的“尽力而为”，它有非常具体的匹配模式：必须返回一个在函数作用域内定义的、非引用/非指针类型的局部变量，且该变量不能是函数参数。任何偏离这个结构的写法，都会让编译器放弃优化。
常见破坏点包括：
-
return std::move(obj)：显式转换为右值引用，强制调用移动构造函数，NRVO失效 -
return (obj)或return static_cast：括号或类型转换引入额外表达式层级，部分编译器（尤其是Clang）拒绝优化(obj) -
return flag ? obj : MyClass{}：三元运算符产生多路径对象来源，NRVO不适用 - 函数内有多个
return obj;，哪怕都指向同一个变量：GCC可能在简单分支下尝试，Clang默认不支持，MSVC基本放弃
C++17之后RVO强制，但NRVO仍是“可选优化”
C++17标准只强制要求对prvalue（纯右值）返回进行拷贝省略，比如return MyClass{};或return make_something();这类无名临时对象——这属于RVO范畴，不是NRVO。
而NRVO（返回MyClass obj; return obj;）依然由编译器自主决定是否执行。这意味着：
- 即使你写了完全合规的NRVO代码，在
-O0调试模式下它几乎一定被禁用 - GCC 12+ 在
-O2下对单return+ 无异常路径的函数较激进；Clang 16+ 对含try块的函数仍可能保留NRVO，但MSVC /std:c++17 下若类定义了用户提供的移动构造函数，有时会退回到移动而非优化 - 没有标准方式检测NRVO是否发生，
__has_feature或宏判断不可靠
怎么验证你的代码触发了NRVO？
最直接的办法是观察构造/析构/移动函数的调用次数。给类加上带打印的特殊成员函数，然后用-fno-elide-constructors（GCC/Clang）或/Od（MSVC）对比开关优化前后的输出。
例如：
S make_s() { S s; return s; }
- 启用优化时只输出
S()→ NRVO成功 - 加
-fno-elide-constructors后出现move或copy→ 确认原本被省略的操作
别为了“看起来高效”而手动std::move
很多人看到“移动比拷贝快”，就习惯性在返回前加std::move。但在NRVO场景下，这是典型负优化：它把原本可能直接构造在目标位置的对象，强行变成一次移动构造，反而多了一次函数调用开销。
真实性能差异往往在纳秒级，但累积在高频函数（如容器push_back内部、游戏帧循环中的状态快照生成）里会被放大。更关键的是，这种写法会掩盖真正需要移动语义的地方——比如返回std::unique_ptr或转发参数时。
记住：return obj; 是NRVO友好写法；return std::move(obj); 是明确告诉编译器“请别优化，我要移动”。除非你实测证明移动构造比NRVO更快（极罕见），否则不要这么干。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
