std::unique_ptr自定义删除器需显式声明模板参数类型，而shared_ptr只需构造时传入；前者类型必须可名状且noexcept，后者支持捕获lambda但需注意拷贝安全。
std::unique_ptr 自定义删除器的写法
C++ 标准库允许为 std::unique_ptr 指定自定义删除器，核心在于：删除器类型必须作为模板参数显式声明，且构造时传入可调用对象（函数指针、lambda、functor）。不声明模板参数会导致编译错误——默认删除器只接受 delete，无法处理数组、C API 资源或非堆内存。
#include <memory>
#include <cstdio><p>// 示例：用 fclose 释放 FILE<em>
std::unique_ptr<FILE, int(</em>)(FILE*)> fp(fopen("test.txt", "r"), fclose);</p><p>// 示例：用 lambda 释放 malloc 分配的内存
auto free_deleter = [](void<em> p) { std::free(p); };
std::unique_ptr<int, decltype(free_deleter)> ptr(
static_cast<int</em>>(std::malloc(sizeof(int))),
free_deleter
);</p>- 删除器类型是
std::unique_ptr模板的第二个参数，不可省略 - 若使用 lambda，需用
decltype获取其类型；捕获变量的 lambda 不能用于模板参数（因其类型不可名状） - 函数指针最稳妥，适合 C 风格资源（如
fclose、curl_easy_cleanup）
std::shared_ptr 自定义删除器的传参方式
std::shared_ptr 不要求在模板中声明删除器类型，删除器作为构造函数参数传入即可，类型擦除由内部控制。这更灵活，但要注意：删除器对象会被拷贝进控制块，若删除器含状态（如 std::function 包装的 lambda），需确保其拷贝安全。
#include <memory>
#include <iostream><p>struct LogDeleter {
void operator()(int* p) const {
std::cout << "Deleting int at " << p << "\n";
delete p;
}
};</p><p>auto sp1 = std::shared_ptr<int>(new int(42), LogDeleter{}); // OK：类型自动推导</p><p>auto sp2 = std::shared_ptr<int>(new int(42),
[](int* p) { std::cout << "lambda delete\n"; delete p; }); // OK：无捕获 lambda 可隐式转换</p><p>auto sp3 = std::shared_ptr<int>(new int(42),
std::function<void(int<em>)>([](int</em> p) { delete p; })); // OK，但有额外开销</p>- 不需要模板参数声明删除器类型，这是和
unique_ptr最关键的区别 - 捕获变量的 lambda 可直接传入（因为构造函数接受通用可调用对象），但注意闭包生命周期不能短于
shared_ptr - 避免把大对象（如含缓冲区的 functor）反复拷贝进控制块，影响性能
常见 Deleter 错误与资源泄漏风险
自定义删除器出错往往不报编译错误，而是导致未定义行为或资源泄漏。典型问题包括：
立即学习“C++免费学习笔记（深入）”；
unique_ptr<T[], D>忘记指定数组特化，仍用默认delete（应为delete[]）删除器中抛异常：C++11 起，
unique_ptr析构时若删除器抛异常会调用std::terminate把非空终止字符串传给
std::string构造函数后，用c_str()得到的指针被unique_ptr管理并误删C API 返回的“借用指针”被误用为独占所有权（如
SDL_GetKeyboardState返回栈/全局内存，不该 delete）删除器必须是 noexcept（尤其对
unique_ptr）；若逻辑可能失败，应在删除器内吞掉异常并记录错误对 C 数组，优先用
std::unique_ptr<T[]>+ 默认删除器，而非手动写delete[]删除器涉及 C 库资源时，务必查清所有权语义：是 caller owns 还是 library owns
Deleter 的实际应用场景
真正需要自定义删除器，不是为了“炫技”，而是对接外部系统所有权契约：
- 封装 C API：如
sqlite3_stmt<em></em>用sqlite3_finalize，pthread_mutex_t用pthread_mutex_destroy - 内存池/arena 分配：用池的
deallocate替代delete - 文件描述符/句柄：Linux
int fd用close，WindowsHANDLE用CloseHandle - 异步 I/O 中的 completion token 或 buffer：需调用特定回收接口，而非简单释放内存
这些场景的共同点是：资源生命周期不由 new/delete 控制，标准删除器完全失效。此时删除器不是“附加功能”，而是正确性的必要条件。
别把删除器当成通用回调——它只该做一件事：释放底层资源。复杂清理逻辑（如先 flush 再 close）应封装进 RAII 类型本身，而不是塞进删除器里。
