std::unique_ptr自定义删除器有模板参数和构造函数两种写法：前者影响类型、无存储开销但类型不兼容；后者不影响类型、有存储开销但支持带状态删除器，且必须处理空指针。
std::unique_ptr 自定义删除器的两种写法
直接在模板参数里声明删除器类型，或者用构造函数传入可调用对象——前者影响类型，后者只影响行为。不声明类型的话，std::unique_ptr 默认用 delete，没法释放非堆内存或调用特定清理函数。
- 类型声明写法：
std::unique_ptr<int void></int>，此时std::default_delete<int></int>不再适用，类型不兼容 - 构造传入写法：
std::unique_ptr<int> ptr(ptr_raw, [](int* p) { free(p); })</int>，类型仍是std::unique_ptr<int></int>，但行为被覆盖 - 用函数指针、Lambda（捕获为空）、仿函数都行，但 lambda 有捕获时不能做模板参数（类型变复杂），只能走构造传入
- 如果删除器带状态（比如要传文件句柄），必须用构造传入；模板参数方式只接受无状态的可调用物
FILE* 和 windows HANDLE 怎么安全托管
原生资源不是 new 出来的，不能靠 delete 收尾，必须显式调用 fclose 或 CloseHandle。删错或漏删会导致资源泄漏，尤其多线程下更难排查。
-
FILE*示例：std::unique_ptr<file int> fp(fopen("a.txt", "r"), &fclose)</file>，注意删除器签名是int(*)(FILE*)，不是void - Windows
HANDLE示例：std::unique_ptr<void void> h(CreateFile(...), [](HANDLE h) { CloseHandle(h); })</void>，别用decltype(&CloseHandle)——它返回bool，和void(*)(HANDLE)不匹配 - 删除器返回值类型必须和系统 API 一致，否则编译失败；C 风格 API 很多返回
int或BOOL，但std::unique_ptr不关心返回值，只校验签名
自定义删除器带来的类型擦除代价
一旦用了非默认删除器，std::unique_ptr 就从零开销变成带存储开销——函数指针或 lambda 对象得存下来。对高频小对象（比如成千上万个 std::unique_ptr<uint8_t></uint8_t>）可能明显拖慢构造/析构速度。
- 模板参数方式（如
std::unique_ptr<t mydeleter></t>）：删除器是类型一部分，通常内联，无额外存储，但类型膨胀，不同删除器之间不可赋值 - 构造传入方式（如
std::unique_ptr<t>(raw, deleter)</t>）：删除器存为成员，哪怕是个空 lambda 也会占 1 字节（对齐后可能更多），且无法内联调用 - 如果删除逻辑简单且固定（比如总是
free），优先用模板参数方式；如果要动态切换行为（比如根据 flag 选munmap还是free），只能用构造传入，但得接受那点开销
容易踩的坑：移动、拷贝和空指针处理
自定义删除器不会自动处理空指针，也不改变移动语义规则——但很多人以为“只要写了删除器，它就会被安全跳过”，其实不会。
立即学习“C++免费学习笔记（深入）”；
- 删除器总会被调用，哪怕
get()返回nullptr。所以你的删除器开头得自己判空：[](int* p) { if (p) delete p; } - 移动后原
std::unique_ptr变空，但它的删除器还活着；如果用模板参数方式，移动前后删除器类型必须一致，否则编译不过 - 不能拷贝（除非删除器本身可拷贝且你显式定义了拷贝构造），但可以移动——这点和默认
std::unique_ptr一致，别指望加了删除器就变可拷贝 - 用
release()后，删除器就失效了，资源交由你手动管理；这时候别忘了，原来绑定的删除逻辑已经不管用了
自定义删除器真正麻烦的不是写法，而是得想清楚：这个资源生命周期是否真的需要和指针绑定？有没有更简单的 RAII 封装方式？比如 std::FILE 就比 std::unique_ptr<file ...></file> 更直观。