结论：混用 delete 和 delete[] 是未定义行为，会导致崩溃、静默损坏或资源泄漏；根本原因在于析构逻辑和元数据读取差异，且对无析构函数类型同样危险，必须严格配对或改用 vector/unique_ptr 等安全方案。
![c++ delete和delete[]用错会导致什么怎么解决](https://img.php.cn/upload/article/001/221/864/179117881531357.png)
直接说结论：用错 delete 和 delete[] 是未定义行为（UB），不是“可能出问题”，而是“随时崩溃、静默损坏、资源泄漏三选一”，且错误位置和现象往往不匹配，极难调试。
为什么 delete 和 delete[] 不能混用
根本原因不在内存释放本身，而在析构函数调用逻辑和底层元数据读取：
-
delete[]会先尝试从指针前偏移处读取数组长度（用于循环调用每个元素的析构函数），再释放整块内存；delete完全不读这个字段，只调一次析构、释放单个对象大小的内存 - 用
delete释放new[]分配的数组 → 只调第一个元素析构，其余对象的析构函数被跳过（比如没关文件、没 free 子内存）→ 资源泄漏 - 用
delete[]释放new分配的单对象 → 去读不存在的“数组长度”字段 → 读到垃圾值或触发访问违规 → 段错误或堆损坏 - 即使对
int这类无析构函数的类型，混用仍属 UB：标准禁止，不同编译器/运行时实现（如 MSVC 的 _CrtMemBlockHeader）行为不一致，上线后可能突然崩
常见错误现场和对应修复
这些不是“写法不优雅”，而是运行时确定性出错：
-
错误写法：
int* p = new int[10]; delete p;→ 编译通过，但 UB；修复：delete[] p; -
错误写法：
MyClass* arr = new MyClass[5]; delete arr;→ 只析构arr[0]，arr[1..4]的资源全泄漏；修复：delete[] arr; -
错误写法：
int* p = new int(42); delete[] p;→ 对单个int执行数组释放，大概率段错误；修复：delete p; -
二维数组典型错误：
int** mat = new int*[rows]; for(...) mat[i] = new int[cols]; delete[] mat; // 错！顺序反了→ 先删顶层指针，后续delete[] mat[i]访问野指针；修复：先for(...) delete[] mat[i];，再delete[] mat;
智能指针里怎么避免 delete/delete[] 混用
裸 new/delete 是陷阱源头，现代 C++ 应绕过它。但若必须用智能指针管理动态数组，类型声明和删除器必须严格匹配：
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
立即学习“C++免费学习笔记（深入）”；
-
std::unique_ptr<int></int>是特化类型，new int[10]必须配它：std::unique_ptr<int> p(new int[10]);</int>→ 析构自动调delete[] -
std::unique_ptr<int></int>（无[]）只能管new int，配new int[10]会编译失败，别硬 cast -
std::shared_ptr<int></int>没数组特化，必须显式传删除器：std::shared_ptr<int> p(new int[10], [](int* ptr){ delete[] ptr; });</int>→ lambda 必须是空捕获[]，不能带[&]或[=] - 所有智能指针场景下，
p.get()返回的是int*，不是int[]*，所以p[i]合法，但&p[0]或p + 1需谨慎，类型仍是普通指针
真正安全的替代方案
手动配对 new/delete 已是技术债。生产代码中应默认规避：
- 用
std::vector<t></t>替代T*数组：自动管理内存+拷贝语义+边界检查（debug 模式），vector内存连续，性能无损 - 用
std::array<t n></t>替代栈上固定大小数组，零开销 - 若需裸指针语义（如对接 C API），优先用
std::unique_ptr<t deleter></t>封装，把delete[]绑定在类型系统里 - 启用编译器警告：
-Wmismatched-new-delete（Clang/GCC）可捕获大部分静态可判的混用，但无法覆盖运行时分支路径
最易被忽略的一点：即使你确认当前用的是 int 或 char，也不代表未来不会把类型改成自定义类——混用习惯一旦养成，重构时必然踩坑。真正的解决不是“这次修对”，而是让错误无法发生。
