std::unique_ptr自定义删除器需显式声明模板参数类型，而shared_ptr只需构造时传入；前者类型必须可名状且noexcept，后者支持捕获Lambda但需注意拷贝安全。
std::unique_ptr 自定义删除器的写法
c++ 标准库允许为 std::unique_ptr 指定自定义删除器，核心在于：删除器类型必须作为模板参数显式声明，且构造时传入可调用对象（函数指针、lambda、functor）。不声明模板参数会导致编译错误——默认删除器只接受 delete，无法处理数组、C API 资源或非堆内存。
#include #include // 示例：用 fclose 释放 FILE std::unique_ptrint( )(FILE*)> fp(fopen("test.txt", "r"), fclose);
// 示例：用 lambda 释放 malloc 分配的内存 auto free_deleter = [](void p) { std::free(p); }; std::unique_ptr ptr( static_cast>(std::malloc(sizeof(int))), free_deleter );
- 删除器类型是
std::unique_ptr模板的第二个参数，不可省略 - 若使用 lambda，需用
decltype获取其类型；捕获变量的 lambda 不能用于模板参数（因其类型不可名状） - 函数指针最稳妥，适合 C 风格资源（如
fclose、curl_easy_cleanup）
std::shared_ptr 自定义删除器的传参方式
std::shared_ptr 不要求在模板中声明删除器类型，删除器作为构造函数参数传入即可，类型擦除由内部控制。这更灵活，但要注意：删除器对象会被拷贝进控制块，若删除器含状态（如 std::function 包装的 lambda），需确保其拷贝安全。
#include #include struct LogDeleter { void operator()(int* p) const { std::cout << "Deleting int at " << p << "n"; delete p; } };
auto sp1 = std::shared_ptr(new int(42), LogDeleter{}); // OK：类型自动推导
auto sp2 = std::shared_ptr(new int(42), [](int* p) { std::cout << "lambda deleten"; delete p; }); // OK：无捕获 lambda 可隐式转换
auto sp3 = std::shared_ptr(new int(42), std::function)>([](int p) { delete p; })); // OK，但有额外开销
- 不需要模板参数声明删除器类型，这是和
unique_ptr最关键的区别 - 捕获变量的 lambda 可直接传入（因为构造函数接受通用可调用对象），但注意闭包生命周期不能短于
shared_ptr - 避免把大对象（如含缓冲区的 functor）反复拷贝进控制块，影响性能
常见 Deleter 错误与资源泄漏风险
自定义删除器出错往往不报编译错误，而是导致未定义行为或资源泄漏。典型问题包括：
立即学习“C++免费学习笔记（深入）”；
-
unique_ptr忘记指定数组特化，仍用默认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+ 默认删除器，而非手动写delete[]删除器 -
涉及 C 库资源时，务必查清所有权语义：是 caller owns 还是 library owns
Deleter 的实际应用场景
真正需要自定义删除器，不是为了“炫技”，而是对接外部系统所有权契约：
- 封装 C API：如
sqlite3_stmt用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 类型本身，而不是塞进删除器里。