直接返回 std::unique_ptr 安全且推荐，编译器自动触发移动语义；函数签名应为 std::unique_ptr<T>，禁用引用返回；移动具名变量后其为空属正常行为。
返回 std::unique_ptr 是安全且推荐的做法
直接返回 std::unique_ptr 不仅合法，而且是 C++11 之后管理动态资源的首选方式。编译器会自动触发移动语义（调用移动构造函数），避免深拷贝——而 std::unique_ptr 根本禁止拷贝，所以你根本不用手动写 std::move（除非返回的是左值）。
常见错误是试图返回裸指针或用 std::move 包裹一个刚构造的临时对象，反而干扰了返回值优化（RVO）和移动优化。
- ✅ 正确：直接
return std::make_unique<t>(...)</t>或return std::unique_ptr<t>(new T)</t> - ❌ 错误：写成
return std::move(ptr)，其中ptr是函数内定义的局部std::unique_ptr变量（这会阻止 RVO，且无必要） - ⚠️ 注意：
std::make_unique不支持初始化列表或私有构造函数（某些老编译器），此时需退回到std::unique_ptr<t>(new T{...})</t>
函数签名怎么写才不踩坑
返回类型必须明确为 std::unique_ptr<t></t>，不能是 std::unique_ptr<t>&</t> 或 const std::unique_ptr<t>&</t>——后者无法绑定到临时对象，会导致编译失败；前者则可能引发悬垂引用。
参数传递也需注意：如果函数内部需要“接管”外部传入的资源，应接收 std::unique_ptr<t></t> 值参（触发移动），而不是引用。
立即学习“C++免费学习笔记（深入）”；
- ✅ 推荐返回签名：
std::unique_ptr<foo> create_foo();</foo> - ❌ 危险签名：
std::unique_ptr<foo>& create_foo();</foo>（返回局部变量引用） - ✅ 若需转移入参：
void process(std::unique_ptr<bar> bar);</bar>—— 调用方写process(std::move(b))
为什么有时返回后原指针变空？
这不是 bug，是移动语义的正常表现。当你从一个具名变量（左值）返回时，编译器不会自动移动，必须显式调用 std::move，而移动后该变量进入有效但未指定状态（通常为空）。
典型场景：函数内先创建、再根据条件返回不同对象，或封装了资源获取逻辑的中间变量。
- 例如：
std::unique_ptr<int> p = std::make_unique<int>(42); return std::move(p);</int></int>→p返回后为nullptr - 但
return std::make_unique<int>(42);</int>→ 没有左值，无需std::move，也不存在“变空”问题 - 检查是否为空：用
if (!ptr)或if (ptr == nullptr)，别用ptr.get() == nullptr（冗余）
和 std::shared_ptr 混用要注意什么
不能隐式转换：std::unique_ptr 不能直接赋给 std::shared_ptr，但可以显式释放所有权后构造：
std::unique_ptr<int> up = std::make_unique<int>(100); std::shared_ptr<int> sp(std::move(up)); // OK：接管 // std::shared_ptr<int> sp2 = up; // ❌ 编译失败
反过来更危险：从 std::shared_ptr 构造 std::unique_ptr 会破坏共享语义，标准库根本不允许（没提供相应构造函数）。
性能提示：如果函数返回值后续大概率会被多个所有者持有，直接返回 std::shared_ptr 更合适；若明确是单一所有权移交，std::unique_ptr 开销更低、语义更清晰。
真正容易被忽略的是：跨 DLL 边界返回 std::unique_ptr 时，如果 new/delete 分配器不一致（比如 DLL 和 EXE 使用不同 CRT），会导致运行时崩溃——这时得用自定义删除器绑定分配器，或者改用裸指针 + 约定接口。
