delete[]触发“Heap Corruption Detected”并非其自身错误，而是此前越界写、错配释放或重复释放等堆破坏行为在释放时才被检测到。
为什么 delete[] 会触发 “Heap Corruption Detected”
这不是 delete[] 本身的问题，而是它在“替前面的错误背锅”。Windows 的 CRT（如 Debug Heap）通常只在真正释放内存时做完整性校验——一旦发现堆元数据被篡改（比如越界写、重复释放、用错配对操作符），就立刻报这个错误。所以看到这个提示，说明问题早发生了，只是现在才暴露。
常见诱因包括：
-
new int[10]分配后，写了arr[10] = 42（越界写入，踩坏后续块的 header） - 用
delete释放了new[]分配的数组（未调用析构、header 解析错乱） - 对同一指针调用了两次
delete[]（第二次释放时 header 已失效） - 指针被移动过：
int* p = new int[5]; p++;，再delete[] p（地址不匹配 header）
如何快速定位越界写或非法释放
启用 Visual Studio 的调试堆检测功能，比等崩溃更早发现问题：
- 在程序开头加：
_CrtSetDbgFlag(_CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF); - 配合
_CrtSetBreakAlloc(123);（123 是分配序号，从输出窗口的 “{123}” 找到哪次new出问题） - 使用 AddressSanitizer（Clang/GCC）或 `/fsanitize=address` 编译，能直接标出越界写行号
注意：Release 模式下这些检测大多失效，务必在 Debug 下复现并排查。
立即学习“C++免费学习笔记（深入）”；
new[] 和 delete[] 的配对规则不能靠猜
C++ 不强制你配对，但错配会导致未定义行为——而 Windows 堆检查器会把它变成可复现的崩溃。关键点：
- 用
new T[n]→ 必须用delete[] ptr；用new T→ 必须用delete ptr - 即使
T是内置类型（如int），也不能混用：delete释放new[]可能不立即崩，但会破坏堆结构 - 如果封装在类里，确保拷贝/赋值后，析构函数里只对合法、未释放过的指针调用
delete[]
示例错误：
int* p = new int[5]; delete p; // ❌ 错误：应为 delete[] p
更安全的替代方案：别手动管理数组
99% 的场景下，你不需要裸 new[]/delete[]。现代 C++ 提供更可靠的选择：
- 固定大小？用
std::array<int, 5>—— 栈上分配，无释放负担 - 运行时大小？用
std::vector<int>—— 自动管理堆内存，支持移动语义，异常安全 - 需要 C 兼容接口？
std::vector::data()返回int*，且保证连续
如果你必须用裸指针（如对接 C API），至少用 std::unique_ptr<int[]> 包一层：auto p = std::make_unique<int[]>(10);，它自动绑定 delete[]，杜绝忘记或错配。
堆损坏的根源往往不在释放那一行，而在之前几十行代码里悄悄越界的写操作——盯住所有数组访问下标、指针算术和内存所有权转移，比反复检查 delete[] 本身更有用。
