用 free 释放 new[] 分配的内存会导致析构函数不被调用、堆元数据损坏及未定义行为，必须使用 delete[] 匹配 new[]。

用 free 释放 new[] 分配的内存会跳过析构函数调用

对自定义类型（比如 class 或 struct）数组，new[] 不仅分配内存，还会为每个元素调用构造函数；而 free 完全不知道这些，它只做一件事：把指针传给底层堆管理器并标记那块内存为可复用。结果就是所有对象的析构函数一个都不会执行——资源泄漏、文件句柄未关闭、锁未释放、内部缓冲区未清理，全可能发生。

对 int、double 这类内置类型，因为没有析构函数，表面看程序可能“不崩溃”，但这只是侥幸。行为未定义（UB），不同编译器/标准库实现可能在后续 malloc/new 中暴露出内存布局错乱、越界访问或静默损坏。

free 和 delete[] 的底层内存布局不兼容

new[] 分配时，多数 C++ 运行时会在用户可见内存前悄悄多申请几个字节，用来存数组长度（供 delete[] 读取后正确调用 N 次析构）。free 不会读这个长度字段，而是直接把传入指针当“用户起始地址”去释放——实际释放的内存块可能偏移、大小错误，导致堆元数据损坏。

常见表现包括：

C++ 算法竞赛自动化测试数据生成与校验框架

根据原题生成新题面、验证器及完整测试数据，自动套用 testlib 模板，用于用户要求生成测试数据时。

下载

• 后续任何 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[] 的结果——不是“能不能”，而是“不该”。

C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！