com对象不可用std::shared_ptr默认管理，因需addref/release控制生命周期；须用noexcept自定义deleter绑定release，推荐模板函数封装；避免与atl的ccomptr混用以防重复release。
COM对象不能直接用 std::shared_ptr 管理
因为 COM 对象的生命周期靠 AddRef / Release 控制，而 std::shared_ptr 默认调用 delete —— 这会绕过 Release，导致内存泄漏或崩溃。
常见错误现象：std::shared_ptr<iunknown>(pUnk)</iunknown> 构造后一出作用域就 crash，或者资源没释放；调试时看到 Release 被调了但不是 COM 自己的实现。
- 必须传入自定义 deleter，显式调用
Release() - deleter 里不能判空再调
Release（COM 规范要求Release自己处理 NULL） - 注意
IUnknown*和具体接口指针（如ID3D11Device*）都适用同一套逻辑
用 std::shared_ptr + 自定义 deleter 安全包装 COM 指针
核心是把 Release 绑定为析构行为。不要手写 lambda 每次都重复，封装成可复用的函数：
template<typename T>
void com_deleter(T* p) noexcept {
if (p) p->Release();
}
<p>// 使用方式：
std::shared_ptr<ID3D11Device> device_ptr(pDevice, com_deleter<ID3D11Device>);- deleter 必须是
noexcept，否则shared_ptr析构可能抛异常中断 Release 流程 - 模板函数比泛型 lambda 更易内联，也避免捕获问题
- 如果 COM 接口继承自
IUnknown，用IUnknown*也能 work，但类型信息丢失，不推荐
别碰 std::unique_ptr 的默认构造陷阱
std::unique_ptr 默认用 delete，直接传 COM 指针等于埋雷。即使写了 custom deleter，也要小心初始化时机：
立即学习“C++免费学习笔记（深入）”；
- 绝不能这样写：
std::unique_ptr<iunknown> ptr(pUnk);</iunknown>—— 编译可能过，运行必崩 - 正确写法必须显式指定 deleter 类型：
std::unique_ptr<iunknown void> ptr(pUnk, com_deleter<iunknown>);</iunknown></iunknown> - 更稳妥的是用
std::unique_ptr的别名模板（C++17 起）：using com_ptr = std::unique_ptr<t void></t>，避免每次写长类型 - COM 场景下
unique_ptr优势有限：多数 COM 对象需要多处引用（比如设备和上下文共享ID3D11Device），shared_ptr更自然
COM 智能指针和 ATL 的 CComPtr 不要混用
ATL 的 CComPtr 是栈上 RAII 封装，内部自动调 AddRef/Release，但它不是标准智能指针，和 std::shared_ptr 之间没有隐式转换。
- 混合使用会导致重复 Release：
CComPtr<iunknown> atlPtr = pUnk; auto sp = std::shared_ptr<iunknown>(atlPtr, com_deleter);</iunknown></iunknown>—— 此时pUnk已被atlPtrAddRef 过，sp 析构又 Release 一次，引用计数错乱 - 如果已有 ATL 代码基，统一用
CComPtr；新模块想用标准库，就彻底脱离 ATL 指针，从原始CoCreateInstance或QueryInterface返回值开始接管 -
CComPtr的Detach()可以交出裸指针给shared_ptr，但务必确保原CComPtr不再访问该对象
真正麻烦的不是怎么写 wrapper，而是 COM 对象跨线程、跨 DLL 时的 Release 调用点是否在正确的 COM 套间里 —— 这个层面智能指针帮不上忙，得靠设计约束。
