delete释放new[]分配的内存会触发未定义行为，大概率导致程序崩溃或数据损坏；delete[]释放new分配的单个对象同样未定义，可能引发堆污染或析构错乱。
![c++中delete和delete[]混用会发生什么？ (内存管理陷阱)](https://img.php.cn/upload/article/001/431/639/177069390261078.jpg)
delete 释放 new\[\] 分配的内存会怎样
直接触发未定义行为，大概率程序崩溃或数据损坏。C++ 标准不保证任何结果，但现实中常见的是析构函数只调用一次（而非数组每个元素），且 operator delete[] 的内存布局元信息被 operator delete 错误解析，可能破坏堆管理器内部结构。
实操建议：
- new[] 配 delete[]，new 配 delete —— 没有例外，编译器不会帮你检查匹配性
- 如果用
std::vector或std::unique_ptr，就完全绕过这个风险 - 静态分析工具（如 clang++ -fsanitize=address）能捕获部分混用场景，但不是万能的
delete\[\] 释放 new 分配的单个对象会怎样
同样属于未定义行为，但表现更隐蔽：可能不崩溃，却悄悄越界读取（寻找数组长度标记），或把单个对象头当数组头处理，导致 operator delete[] 尝试调用不存在的析构函数数组。
常见错误现象：
立即学习“C++免费学习笔记（深入）”；
- 释放后对象成员变量变成随机值（析构逻辑错乱）
- 后续 new/new[] 分配失败或返回异常地址（堆被污染）
- 在某些平台（如 Windows MSVC debug 模式）直接断言失败，报错
_BLOCK_TYPE_IS_VALID
为什么编译器不禁止 delete/delete\[\] 混用
因为类型信息在运行时丢失：new 表达式生成的指针类型是 T*，无论来自 new 还是 new[]；编译器无法仅凭指针推断原始分配方式。
关键点：
-
sizeof(T)和数组长度不编码在指针里，也不存于标准 ABI - 即使启用 RTTI，
dynamic_cast或typeid对裸指针无效 - Clang/GCC 的
-Wmismatched-new-delete能检测部分明显不匹配（如函数内联可见时），但跨函数、跨编译单元就失效
如何避免踩坑（实际项目中管用的几条）
靠人盯代码不可靠，得靠约束和工具。
- 禁用裸 new/new[]：统一用
std::make_unique（单个）或() std::make_unique（数组）(n) - 若必须用裸指针，把 new[] 和 delete[] 封装进 RAII 类（如自定义
ArrayPtr），构造/析构绑定明确 - 在 CI 中强制开启 ASan（AddressSanitizer）和 UBSan（UndefinedBehaviorSanitizer），混用会直接报
misaligned-pointer或delete-mismatch - 注意
placement new场景：那里 delete/delete[] 更容易写错，且 no-op 的 operator delete 不等于安全
最麻烦的其实是遗留 C 风格代码里穿插的 malloc/free 和 new/delete —— 它们根本不在一个管理体系里，混用等于主动放弃内存安全边界。
