std::unique_ptr作为函数返回值绝不会调用拷贝构造函数，只触发移动构造；C++17起自动视为右值移动，移动后原对象必为空，需检查状态以防解引用。
std::unique_ptr 返回值不会发生拷贝，只触发移动
直接说结论：
作为函数返回值时，**绝不会调用拷贝构造函数**（它被显式删除了），而是调用移动构造函数。即使编译器没启用 RVO/NRVO，行为也安全且高效。
常见错误现象：有人看到
就下意识觉得“这不就是复制指针吗”，结果在自定义删除器或资源敏感场景中误判生命周期，导致提前释放或悬空。
的拷贝构造函数和拷贝赋值运算符都是
的，任何试图拷贝的代码在编译期就报错，例如：
→ 编译失败
返回语句中的
是一个具名对象，按 C++17 规则，即使没写
，也会自动视为右值并触发移动（C++11/14 中依赖编译器优化，但主流编译器都做了保证）
如果函数返回类型是
，而你返回的是
（如派生类），需确保
是
的可访问、非私有基类，否则移动构造失败
什么时候必须显式写 std::move？
只有一种典型场景：当你返回的是一个局部
变量，但它在 return 前被多次使用、或存在分支逻辑，编译器可能无法确定是否可安全应用移动语义。
使用场景：比如函数里做了条件判断，最后统一 return，或者你在 return 前调用了
或
等操作，此时变量状态已变，编译器不再将其视为“可移动的纯右值”。
立即学习
“
C++免费学习笔记（深入）
”；
安全写法：
—— 显式告诉编译器：“请无条件移动，别犹豫”
错误写法：
→ 返回裸指针，
管理权丢失，资源泄漏风险
性能影响：
本身是零开销转换（仅类型转换），不触发实际移动；真正开销在移动构造函数内，通常只是指针和删除器的转移，O(1)
移动后原 unique_ptr 的状态必须检查
移动操作会使源
变成空状态（
），这不是可选行为，而是标准强制要求。忽略这点容易引发空解引用。
C知道
CSDN推出的一款AI技术问答工具
下载
常见错误现象：在 return 前还试图用移动过的
调用
或
，运行时报
或未定义行为。
移动后立即检查：
不要假设“我刚 move 过，它肯定为空”就跳过检查——某些调试构建或自定义删除器可能改变行为
注意：移动构造/赋值后，源对象的
、
都返回
，这是唯一可依赖的状态
和 shared_ptr 混用时的隐含陷阱
把
返回值赋给
是合法的，但会触发一次控制块分配和引用计数初始化，不是零成本转换。
使用场景：需要把独占所有权临时转为共享管理（比如日志模块接收资源但不独占）。
正确写法：
—— 移动构造，避免拷贝
错误写法：
→ 双重管理！原始
和新
各自析构，UB
兼容性影响：C++11 起支持
从
移动构造；但若
有自定义删除器，该删除器必须可移动，否则编译失败
移动语义不是黑箱，
的返回行为清晰、可预测，但前提是别绕过它的约束去“手动取指针”或“二次释放”。最常被忽略的，其实是移动后对原对象的空状态处理——它不像
那样还能继续用，一动就废。
std::unique_ptrreturn ptr;std::unique_ptr= deletestd::unique_ptr p2 = p1; ptrstd::move(ptr)std::unique_ptrstd::unique_ptrTUstd::unique_ptrptr.get()ptr.release()return std::move(ptr);return ptr.release();std::unique_ptrstd::movestd::unique_ptrget() == nullptrptr->*segmentation faultif (!ptr) { /* 已移交 */ }get()operator bool()falsestd::unique_ptrstd::shared_ptrstd::shared_ptr sp = std::move(up); std::shared_ptr sp(up.get()); upspstd::shared_ptrstd::unique_ptrunique_ptrstd::unique_ptrshared_ptr