unique_ptr::release() 交出指针控制权而不释放内存，返回裸指针并置 unique_ptr 为空；后续需手动匹配 delete/delete[]，且不触发自定义删除器，仅适用于移交所有权给明确承诺接管的C接口。
unique_ptr::release() 的真实作用：不是销毁，是交出控制权
unique_ptr::release() 不会调用 delete，也不释放内存；它只是把内部裸指针拿出来，同时让 unique_ptr 自己变为空（get() == nullptr）。你拿到的指针，后续必须手动管理——不 delete 就泄漏，重复 delete 就崩溃。
- 典型误用：
int* p = ptr.release(); delete p;—— 看似合理，但若ptr原本管理的是数组（unique_ptr<int></int>），delete p会触发未定义行为，必须用delete[] p - 正确匹配：释放前需确认
unique_ptr类型，unique_ptr<t></t>对应delete，unique_ptr<t></t>对应delete[] - 常见场景：移交指针给 C API（如
some_c_function(ptr.release())），此时你要确保该 C 函数明确承诺接管并释放内存
为什么不能对同一个 unique_ptr 多次调用 release()
第二次调用 release() 会返回 nullptr，因为第一次已清空内部指针。这不是错误，但容易掩盖逻辑问题——比如误以为还能“再取一次”。
- 调试线索：若
release()后得到nullptr，先检查是否已调用过，或是否被移动（std::move(ptr)后效果等同于release()） - 无异常保证：
release()是noexcept，不会抛异常，但也不会帮你做任何校验 - 与
reset()的关键区别：reset()会先释放旧资源（调用delete），再赋新值；release()完全跳过释放步骤
release() 在自定义删除器下的行为细节
如果 unique_ptr 使用了自定义删除器（如 unique_ptr<foo mydeleter></foo>），release() 依然只交出指针，完全不触发删除器。删除器仅在析构、reset() 或赋值覆盖时生效。
- 风险点：交出指针后，若忘记用对应方式清理（比如删除器里写了日志、解锁互斥量），这些副作用就永久丢失
- 示例：
unique_ptr<file decltype> fp(fopen("x.txt", "r"), &fclose); auto raw = fp.release();</file>—— 此时fclose不会被调用，文件句柄泄露 - 替代思路：若需延迟清理，优先考虑把清理逻辑封装进 lambda 删除器，而非依赖
release()后的手动调用
什么时候该用 release()？多数时候其实不该用
90% 的 C++ 项目中，release() 属于“有明确互操作需求才打开的后门”。滥用它等于主动放弃 RAII 的安全边界。
立即学习“C++免费学习笔记（深入）”；
- 真正合理的使用条件：必须把裸指针传给无法修改的遗留 C 接口，且该接口文档明确说明“接管所有权”
- 危险替代方案：用
get()获取指针但不释放——这更常见，但要注意：只要unique_ptr还活着，你就不能delete它返回的指针 - 现代替代：C++17 起可考虑
std::optional<unique_ptr>></unique_ptr>或工厂函数返回值，避免中途交出所有权
最易忽略的一点：release 后的裸指针没有类型信息残留——编译器无法提醒你该用 delete 还是 delete[]，也无法检查是否重复释放。这部分责任 100% 落在程序员手上，且毫无运行时保护。
