std::unique_ptr的删除器必须是可默认构造的可调用类型，且作为模板参数显式指定；Lambda仅空捕获时可用，否则需用functor类封装状态与上下文逻辑。
std::unique_ptr 的删除器必须是可调用对象，且类型需在模板参数中显式声明
默认情况下 std::unique_ptr 使用 delete，但管理文件句柄、POSIX 信号量、OpenGL 纹理 ID 等非内存资源时，必须替换为对应释放逻辑。关键点在于：删除器类型是 std::unique_ptr 模板的一部分，不能靠运行时推导。
常见错误是写成 std::unique_ptr 然后试图用 lambda 赋值——编译直接失败，因为默认删除器是 std::default_delete，和 void(*)(FILE*) 不兼容。
- 正确做法：把删除器类型作为第二个模板参数传入，例如
std::unique_ptr - 更安全写法：用
std::function或自定义 Struct，避免函数指针退化问题（尤其涉及重载或模板函数时） - 若删除器有状态（比如带日志前缀），必须用类类型，且该类需满足 MoveConstructible
用 lambda 做删除器时，必须捕获为空且显式指定类型
lambda 只有在不捕获任何变量时才是可默认构造的，才能作为 std::unique_ptr 的删除器类型。否则无法满足 unique_ptr 对删除器的移动/构造要求。
示例：管理一个手动分配的 POSIX 信号量
立即学习“C++免费学习笔记（深入）”；
auto sem_deleter = [](sem_t* s) { sem_close(s); }; std::unique_ptr sem_ptr{ sem_open("/mysem", O_CREAT, 0644, 1), sem_deleter }; - 不能写
[&]或[=]，哪怕只捕获一个int也会让类型不可默认构造 - 如果删除逻辑复杂，建议封装为命名函数或 functor 类，而非长 lambda
- 注意
sem_open失败返回SEM_FaiLED，需在构造前检查，否则传入空指针进删除器会崩溃
自定义删除器影响 move 语义和异常安全性
删除器类型参与 std::unique_ptr 的类型系统，不同删除器类型的 unique_ptr 之间不能隐式转换，甚至不能互相 move —— 除非删除器类型完全一致。
- 两个
std::unique_ptr可以 move，但换成std::unique_ptr就不行> - 删除器构造若抛异常（如内部 new 失败），会导致
unique_ptr构造失败，资源泄漏风险由你控制；标准delete删除器不抛异常，但自定义的未必 - 若删除器含非 trivial 操作（如加锁、发网络请求），要考虑其执行时机：它在 unique_ptr 离开作用域或被 reset 时同步调用，阻塞当前线程
管理 OpenGL 资源时，删除器必须绑定当前 GL 上下文
像 glDeleteTextures 这类函数，必须在创建该纹理的同一 OpenGL 上下文中调用，否则行为未定义。这意味着删除器不能只是个裸函数指针。
典型做法是把上下文标识（如 GLXContext 或 EGLContext）存入删除器状态中，并在调用 glDelete* 前确保上下文已激活。
- 推荐用轻量 functor 类，成员保存 context handle，
operator()中做上下文切换 + 删除 + 切回 - 避免在删除器里做耗时操作（如等待 GPU 完成），这会让析构变慢且难以调试
- 注意多线程：OpenGL 上下文通常不支持跨线程调用，删除器必须保证执行在线程安全的前提下
c++ 标准没规定删除器执行时的线程上下文，也没保证是否在栈展开期间调用——这些全由你负责对齐实际资源生命周期约束。