unique_ptr不可复制只可移动，需用std::move转移所有权；数组须用default_delete或make_unique；混用裸指针易致double-free或悬垂指针；容器操作应优先使用make_unique保证异常安全。
unique_ptr 不能复制，但能移动——别用 = 赋值
很多人写 unique_ptr<int> p1 = make_unique<int>(42); unique_ptr<int> p2 = p1;</int></int></int>，编译直接报错：use of deleted function 'std::unique_ptr<_tp _dp>::unique_ptr(const std::unique_ptr<_tp _dp>&)'</_tp></_tp>。这是设计使然：它叫 “unique” 就是强调唯一所有权，复制会引发双重释放风险。
正确做法只有移动：
- 用
std::move(p1)显式转移所有权：unique_ptr<int> p2 = std::move(p1);</int>—— 此后p1变成空（p1 == nullptr） - 函数传参/返回时也靠移动：
void take_ownership(unique_ptr<int> p) { ... }</int>，调用时直接传std::move(p1)或返回临时对象（编译器自动移动） - 别试图用
get()拿裸指针再构造新unique_ptr，那等于绕过所有权管理，极易 double-free
自定义删除器必须和类型匹配，否则运行时崩溃
常见错误是给数组用默认删除器，或删除器签名不对。比如：unique_ptr<int> p(new int[10]);</int> 看似没问题，但如果后续你写了 p.reset(new int[5]);，而没指定数组删除器，析构时仍调用 delete 而非 delete[]，UB（未定义行为），大概率段错误。
安全写法分两种场景：
立即学习“C++免费学习笔记（深入）”；
- 数组：必须显式指定
default_delete<int></int>，即unique_ptr<int default_delete>> p(new int[10]);</int>；更推荐用make_unique<int>(10)</int>，它自动选对删除器 - 自定义资源（如 FILE*）：删除器类型要和
unique_ptr模板参数一致，例如unique_ptr<file decltype> fp(fopen("x.txt", "r"), &fclose);</file>，漏掉decltype(&fclose)或传错函数指针类型，编译失败 - 注意：删除器对象需满足 MoveConstructible，lambda 若捕获变量可能不满足，此时得用函数对象或
std::function（但有额外开销）
和 raw pointer 混用是内存泄漏或悬垂指针的温床
典型陷阱：从 unique_ptr 拿出裸指针传给旧接口，又忘了谁该释放。比如：void legacy_api(int* p); unique_ptr<int> p = make_unique<int>(1); legacy_api(p.get());</int></int> —— 如果 legacy_api 内部把 p 存起来、后续又 delete，而 unique_ptr 析构时再删一次，就崩了。
判断依据很简单：只要出现 get()、release()，立刻问自己两个问题：
-
release()后，你是否 100% 手动接管了内存生命周期？常见错：只调release()却没存返回值，资源直接泄露 -
get()返回的指针，是否保证在unique_ptr生存期内使用？超出范围就是悬垂指针 - 第三方库要求裸指针时，优先查它有没有 move-aware 接口；没有的话，用
release()前务必确认库不负责释放（比如只读访问），否则换shared_ptr或重写封装
和容器一起用要注意移动语义和异常安全
往 vector<unique_ptr>></unique_ptr> 里塞对象，常见误写：v.push_back(unique_ptr<int>(new int(1)));</int>。虽然能编译，但若 push_back 过程中发生异常（如扩容失败），new int(1) 的内存就泄漏了——因为 unique_ptr 构造成功前，异常抛出，原始裸指针已丢失。
必须用工厂函数兜底：
- 永远优先用
make_unique：v.push_back(make_unique<int>(1));</int>，它先分配内存再构造对象，异常安全 - 容器元素移动成本低，但别在循环里反复
push_back(std::move(x))后又继续用x，容易误用空指针 - 如果容器要跨线程传递，
unique_ptr本身不线程安全——移动操作不是原子的，多线程同时对同一unique_ptr调用reset或移动，结果未定义
最常被忽略的一点：unique_ptr 的“独占性”只在代码逻辑层成立，编译器不会帮你检查是否有人偷偷用 get() 拿到指针又长期持有。一旦出现裸指针逃逸，整个智能指针的安全假设就垮了。
