必须在自定义智能指针析构函数中调用无状态、可重入的日志函数，先记录地址与类型信息再释放对象，避免依赖可能已析构的全局资源，并用互斥锁保障多线程安全。
如何让自定义智能指针在析构时触发日志记录
直接结论：必须在自定义智能指针的析构函数中调用日志逻辑，且该逻辑不能依赖 std::shared_ptr 或 std::unique_ptr 管理的日志对象（否则可能引发二次析构或未定义行为）。最稳妥的方式是使用原始指针 + RAII 封装，并把日志函数设计为无状态、可重入的自由函数或静态成员。
实现一个带日志的 UniquePtr 类模板
核心是复刻 std::unique_ptr 的语义，但插入日志点。注意三点：析构时机必须确定；日志内容应包含地址和类型信息；避免在日志中访问已释放对象。
- 析构函数里先保存
ptr_地址和typeid(T).name()，再执行delete ptr_，最后调用日志函数 - 禁止拷贝，只允许移动——否则日志会重复或丢失
- 支持自定义删除器，但默认删除器要和日志解耦；建议日志单独走一个静态回调，而非塞进删除器里
- 示例关键片段：
template<typename t> class UniquePtr { T* ptr_; public: explicit UniquePtr(T* p) : ptr_(p) {} ~UniquePtr() { if (ptr_) { const void* addr = static_cast<const void>(ptr_); std::string type_name = typeid(T).name(); log_destruction(addr, type_name.c_str()); delete ptr_; ptr_ = nullptr; } } // ... 移动构造/赋值、operator->、operator* 等省略 };</const></typename>
为什么不能在删除器里写日志
因为删除器（Deleter）本身可能持有资源或依赖全局状态，而日志系统（如基于 std::ofstream 或第三方库）很可能也依赖静态对象。C++ 静态对象析构顺序是反向的，若删除器里调用了日志，而日志后端此时已被析构，就会导致 crash 或静默失败。
- 典型错误现象：
std::terminate、段错误、日志文件空或乱码 - 更安全的做法是：日志函数只做最小动作——格式化字符串 + 调用
write(2)或fputs到已打开的FILE*，且该FILE*由主程序生命周期管理 - 如果必须用 C++ iostream，确保日志流对象的生命周期长于所有智能指针实例（比如定义为
static inline std::ofstream g_log_file，并在main()开头就打开）
如何避免多线程下日志竞争
多个 UniquePtr 实例并发析构时，日志写入可能交错。这不是智能指针本身的问题，而是日志输出的并发控制问题。
- 最轻量方案：用
std::atomic_flag做自旋锁，保护日志写入临界区（适合低频销毁场景） - 推荐方案：日志函数内部用
std::call_once初始化一个全局std::mutex，然后加锁写入——比每次 new/mutex 更高效 - 绝对不要在析构函数里调用
std::cout ，因为std::cout不是线程安全的，且可能触发内存分配 - 示例锁保护：
static std::mutex g_log_mutex; void log_destruction(const void* addr, const char* type) { std::lock_guard<:mutex> lk(g_log_mutex); fprintf(g_log_fp, "[DESTRUCT] %p (%s)\n", addr, type); }</:mutex>
日志是否写成功不改变对象生命周期，所以务必把日志当作“尽力而为”的旁路操作——它不能抛异常，不能阻塞过久，也不能成为资源释放路径上的单点故障。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
