应优先使用智能指针管理动态内存：std::unique_ptr确保单所有权自动释放，std::shared_ptr配合std::weak_ptr解决共享与循环引用，仅底层场景才谨慎使用new/delete并封装于RAII类中。
new/delete 容易导致内存泄漏和悬垂指针
手动调用 new 分配堆内存后，必须严格配对 delete；一旦分支遗漏、异常抛出、提前 return，delete 就可能被跳过。比如函数中多个 return 路径，或 try/catch 里只在部分分支释放，就会留下泄漏。
更危险的是重复 delete 或访问已 delete 的指针——C++ 不会报错，但行为未定义，常见表现为随机崩溃或数据错乱。
- 异常发生时，
new后的清理代码可能根本不会执行 - 多线程环境下，裸指针共享 + 手动
delete极难保证安全释放时机 - 拷贝对象时若含裸指针成员，浅拷贝会导致多个对象指向同一块内存，谁先
delete谁就制造悬垂指针
std::unique_ptr 自动管理单所有权
std::unique_ptr 在栈上创建，析构时自动调用 delete（或自定义 deleter），无需人工干预。它禁止拷贝，只支持移动，天然表达“唯一拥有者”语义。
适用于：资源只被一个对象持有、生命周期与作用域绑定明确的场景（如工厂函数返回、容器元素、类成员）。
std::unique_ptr<int> ptr = std::make_unique<int>(42); // 函数结束时自动 delete，无需写 delete ptr.get(); // 即使中间抛异常，也会栈展开触发析构</int></int>
- 比裸指针零开销（无引用计数，不额外分配控制块）
-
std::make_unique比直接new更安全：避免 new 成功但构造失败时的泄漏 - 可配合
std::move转移所有权，转移后原指针变空，杜绝重复释放
std::shared_ptr 解决共享所有权问题
当多个对象需要共同持有同一块资源时，裸指针无法安全计数，而 std::shared_ptr 用原子引用计数保证线程安全的释放时机：最后一个 shared_ptr 析构时才真正 delete。
但要注意循环引用——两个 shared_ptr 互相持有对方所指对象，计数永不归零，造成泄漏。
- 用
std::weak_ptr打破循环：它不增加引用计数，访问前需调用lock()检查对象是否还存在 - 不要用裸指针或
get()结果长期保存——它不延长生命周期，容易变成悬垂指针 - 避免从裸指针构造
shared_ptr（如shared_ptr），应优先用(new T) make_shared，减少一次内存分配
哪些情况仍可能需要 new/delete？
极少数底层场景绕不开：编写自定义内存池、实现容器内部存储、与 C API 交互（如接收 void* 并需用 delete 释放）、或性能敏感且能完全掌控生命周期的嵌入式模块。
即便如此，也建议把 new/delete 封装在 RAII 类内部，对外暴露智能指针接口，而不是让调用方直面裸操作。
- 现代 C++ 项目中，95% 以上的动态内存应由
unique_ptr或shared_ptr管理 - 禁用
new/delete并非教条，而是把“谁负责释放”这个易错问题，交给编译器和类型系统强制约束 - 最容易被忽略的一点：智能指针不能解决所有资源管理问题——文件句柄、GPU 显存、数据库连接等，仍需各自对应的 RAII 封装，不能指望
shared_ptr自动 fclose
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
