std::unique_ptr转std::shared_ptr只能通过std::move实现所有权转移，直接用.get()构造会导致双重释放；反之不可行，因shared_ptr共享所有权而unique_ptr要求独占，且use_count()==1非线程安全。
std::unique_ptr 转 std::shared_ptr：只能 move，不能 copy
std::unique_ptr 本质是独占所有权，无法复制；要转成 std::shared_ptr，必须交出控制权，用 std::move() 转移底层指针。这是唯一安全的方式。
- 直接构造
std::shared_ptr时传入已 move 的std::unique_ptr，会接管其资源并初始化引用计数为 1 - 原
std::unique_ptr在 move 后变为nullptr，再访问会 UB（未定义行为） - 不能用
.get()+ 原始指针构造std::shared_ptr—— 这会导致双重 delete（unique_ptr析构时仍尝试释放）
std::unique_ptr<int> up = std::make_unique<int>(42);
std::shared_ptr<int> sp{std::move(up)}; // ✅ 正确：所有权转移
// std::shared_ptr<int> sp2{up.get()}; // ❌ 危险：up 之后析构会重复释放
std::shared_ptr 转 std::unique_ptr：通常不可行，除非你确定只剩一个引用
因为 std::shared_ptr 表示共享所有权，而 std::unique_ptr 要求独占，所以标准库不提供直接转换接口。强行“转”需要先确认引用计数为 1，再用 .release() 拿出裸指针手动构造 —— 但这个过程不安全，且破坏 RAII。
-
sp.use_count() == 1是必要前提，但不是线程安全的判断条件（竞态下可能刚检查完就新增引用） -
sp.reset()或sp = nullptr后，sp.get()变为nullptr，但此时资源已被释放，不能再用于构造unique_ptr - 真正能“等效替代”的做法是：改用
std::shared_ptr并接受共享语义，或重构生命周期，避免中途切换
为什么没有隐式或显式转换函数？
这是设计上的刻意限制，反映两种智能指针的根本差异：
-
std::unique_ptr→std::shared_ptr：move 是单向、明确的所有权移交，语义清晰 -
std::shared_ptr→std::unique_ptr：意味着“我断定此刻没人跟我共享”，但 C++ 无法在运行时可靠验证这一点，强制转换会掩盖潜在竞态或误用 - 标准库不提供
shared_ptr::release()，正是因为释放后无法保证其他副本不继续使用资源
常见错误场景和替代思路
实际开发中，想“转”往往说明接口设计或所有权边界没理清。更稳妥的做法是：
立即学习“C++免费学习笔记（深入）”；
- 函数返回
std::unique_ptr，调用方按需转为std::shared_ptr（如需长期持有或跨线程） - 避免让同一对象既被
unique_ptr又被shared_ptr管理 —— 容易引发 double-free 或悬空指针 - 若需灵活切换，考虑用
std::shared_ptr统一管理，配合weak_ptr规避循环引用 - 极少数确定单引用场景（如工厂内部临时封装），可用
std::shared_ptr::get()+std::unique_ptr自定义 deleter 空操作，但这属于 hack，不推荐
所有权转移不是类型转换，而是语义承诺。搞错方向，轻则内存泄漏，重则崩溃 —— 尤其在多线程或复杂生命周期中，use_count() 的瞬时值根本靠不住。
