用 free 释放 new[] 分配的内存会导致析构函数不被调用、堆元数据损坏及未定义行为，必须使用 delete[] 匹配 new[]。
![c++用free释放new[]创建的动态数组会发生什么](https://img.php.cn/upload/article/001/221/864/179040730844930.png)
用 free 释放 new[] 分配的内存会跳过析构函数调用
对自定义类型（比如 class 或 struct）数组，new[] 不仅分配内存，还会为每个元素调用构造函数；而 free 完全不知道这些，它只做一件事：把指针传给底层堆管理器并标记那块内存为可复用。结果就是所有对象的析构函数一个都不会执行——资源泄漏、文件句柄未关闭、锁未释放、内部缓冲区未清理，全可能发生。
对 int、double 这类内置类型，因为没有析构函数，表面看程序可能“不崩溃”，但这只是侥幸。行为未定义（UB），不同编译器/标准库实现可能在后续 malloc/new 中暴露出内存布局错乱、越界访问或静默损坏。
free 和 delete[] 的底层内存布局不兼容
new[] 分配时，多数 C++ 运行时会在用户可见内存前悄悄多申请几个字节，用来存数组长度（供 delete[] 读取后正确调用 N 次析构）。free 不会读这个长度字段，而是直接把传入指针当“用户起始地址”去释放——实际释放的内存块可能偏移、大小错误，导致堆元数据损坏。
常见表现包括：
立即学习“C++免费学习笔记（深入）”；
- 后续任何
malloc/new调用突然失败或返回异常地址 -
free自身触发abort()或 SIGABRT（尤其在 debug build 下） - Valgrind 报
Invalid free或Mismatched free() / delete / delete []
混用 new[] 和 free 的典型错误场景
这种错误常出现在跨语言接口或遗留 C 代码集成中，比如：
- 用
new[]创建缓冲区传给 C 函数，C 函数里调用free—— 错，应由 C++ 侧用delete[]释放 - 封装动态数组到结构体中，误以为“反正都是释放内存”，统一用
free处理所有指针 - 调试时临时替换
delete[]为free看是否“更快”，忽略语义差异
即使测试没出错，也绝不意味着安全。C++ 标准明确将该行为定义为未定义，编译器无义务诊断，优化器甚至可能基于“不会发生 UB”的假设做激进优化，让问题延后爆发。
真正安全的替代方案
不要试图绕过匹配规则。如果必须和 C 接口协作：
- 用
malloc/free分配 + 手动构造/析构（适用于简单 POD 类型） - 用
std::vector替代裸new[]，对外暴露.data()和.size()给 C 使用，C++ 侧仍由 vector 自动管理生命周期 - 若必须传递裸指针且 C 侧要
free，则 C++ 侧改用malloc分配（但失去构造/析构能力，需自行保障对象状态）
最根本的一点：C++ 的 new[] / delete[] 是一套原子契约，拆开用就等于放弃语言提供的安全边界。哪怕只是 int 数组，也别用 free 去碰 new[] 的结果——不是“能不能”，而是“不该”。
