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