new出的对象必须配对delete，否则内存泄漏且资源无法释放；delete先调析构函数再释放内存，仅对new返回的指针有效，不可与智能指针混用，多态对象需虚析构函数。
new 出来的对象必须配对 delete，否则内存泄漏
手动分配的堆内存不会自动回收，delete 是唯一能触发析构函数并归还内存的操作。不调用 delete，对象的析构函数就不会执行，资源（如文件句柄、socket、自定义缓冲区）大概率泄露。
常见错误现象：
• 程序运行越久越慢，RSS 内存持续上涨
• valgrind --leak-check=full 报大量 “definitely lost”
• 对象内部申请的资源（比如 new int[100]）没被释放，但外层指针被覆盖丢失
- 只对
new返回的指针用delete；对new[]必须用delete[]，否则析构可能只调一次（UB） - 避免重复
delete：删完立刻把指针设为nullptr，防止二次释放崩溃 - 不要
delete栈变量地址、全局变量地址、或malloc得来的指针（该用free）
析构函数调用时机由对象生命周期决定，和 delete 无关
delete 的作用是两步：先调用析构函数，再释放内存块。但析构函数本身什么时候被调用，取决于对象“活到什么时候”——栈对象在作用域结束时自动析构，std::unique_ptr 在自身销毁时调用 delete，而裸指针完全不参与生命周期管理。
容易踩的坑：
• 认为“只要写了析构函数，系统就会帮我清理”，其实裸指针根本不知道自己该不该析构
• 在 delete p; 后继续访问 *p 或调用 p->method()，此时已是野指针（UB）
• 把指向栈对象的指针传给 delete，直接 crash
立即学习“C++免费学习笔记（深入）”；
- 栈对象（如
MyClass obj;）的析构函数在}处自动调用，跟delete毫无关系 -
delete p;会立即调用p所指对象的析构函数 —— 这是它唯一能触发析构的途径（针对堆对象） - 如果类里有
std::vector、std::string等成员，它们的析构由编译器自动生成的默认析构函数保证，无需手动干预
delete 和智能指针混用会直接导致 double-free 或崩溃
用 std::unique_ptr 或 std::shared_ptr 管理的对象，其析构和内存释放由智能指针控制。如果再对原始指针手动 delete，等于同一块内存被释放两次。
典型错误场景：
• auto p = std::make_unique<myclass>();</myclass>，然后又写 delete p.get();
• 把 new 出来的指针交给 std::shared_ptr，之后又 delete 原始指针
• 在回调函数里拿到智能指针持有的原始指针，误以为要自己清理
- 一旦把裸指针交给智能指针（如
std::shared_ptr<t>(new T)</t>），就彻底放弃手动管理权 -
std::unique_ptr::release()会交出所有权，返回裸指针 —— 此时你才需要自己负责delete，但绝大多数情况不该这么做 - 调试时发现
double free or corruption错误，优先检查是否对智能指针管理的对象做了额外delete
多态对象必须用虚析构函数，否则 delete 只调基类析构
当通过基类指针删除派生类对象时（如 Base* p = new Derived;），如果 Base::~Base() 不是 virtual，C++ 只调用 Base 的析构函数，Derived 的析构函数被跳过 —— 成员资源不释放，逻辑被绕过，UB。
表现往往隐蔽：
• 派生类里 new 的缓冲区没被 delete
• 文件没 close，日志没 flush
• 析构函数里的 std::cout << "dtor" 完全没输出
- 只要类设计为基类（尤其有 virtual 函数），就应声明
virtual ~Base() = default; - 纯虚析构函数也得提供定义：
virtual ~Base() {}或= default;，否则链接失败 - 这不是性能优化点，是正确性底线 —— 编译器不会警告，运行期行为未定义
最常被忽略的是：析构顺序本身不能“调整”，它由对象创建方式和作用域嵌套严格决定；你能控制的只有“谁来负责释放”——裸指针？智能指针？还是干脆别上堆。选错管理方式，比写错一行 delete 更难 debug。
