使用placement new构造数组后，能否用delete[]替代显式析构+operator delete[]？

问题场景 #

在创建类类型动态数组时，由于无法直接通过new[]调用非默认构造函数，我采用了placement new的方式手动管理内存与对象构造：

void* memory = operator new[](sizeof(Test) * 8);  // 为8个对象分配原始内存
Test* arr = static_cast<Test*>(memory);  // 转换为目标类型指针

// 使用placement new构造对象
for (int i = 0; i < 8; i++) {
    new (&arr[i]) Test(9);  // 假设Test存在Test(int)构造函数
}

// 使用数组...

// 手动销毁与释放
for (int i = 0; i < 8; i++) {
    arr[i].~Test();  // 显式调用每个对象的析构函数
}
operator delete[](memory);  // 释放原始内存

现在想知道：是否可以用delete[] arr;替代上述的显式析构循环+operator delete[](memory);？我在VS2022中测试运行正常，但担心存在内存泄漏或过度释放的风险。

核心结论 #

绝对不能用delete[] arr;替代原有的释放流程，即使当前测试正常，也属于未定义行为，随时可能引发崩溃、内存损坏等问题。

原因详解 #

1. delete[]的工作逻辑
   delete[]的执行分为两步：

   • 首先读取数组内存块头部的隐藏元数据（通常是数组元素个数），循环调用每个元素的析构函数；
   • 接着调用对应的operator delete[]释放整个内存块。

2. 手动分配内存与new[]的差异
   你通过operator new[]分配的是纯原始内存，没有new[]自动添加的头部元数据。调用delete[] arr;时，编译器会尝试读取不存在的元数据，导致：

   • 读取越界内存区域，触发未定义行为；
   • 错误计算析构函数调用次数（多调用或少调用）；
   • 传递给operator delete[]的内存地址可能不是最初分配的地址，导致释放错误。

3. VS2022测试正常的假象
   某些编译器（比如VS）在特定场景下（例如类的析构函数是 trivial 的）可能不会添加额外元数据，让delete[] arr;看起来能正常工作，但这是依赖编译器实现的行为，不具备可移植性——一旦类的析构函数变为非trivial，或更换编译器/平台，立刻会引发问题。

正确的释放方式 #

必须严格遵循手动构造对应手动析构，分配方式对应释放方式的原则：

• 因placement new仅负责在已分配内存中构造对象，不会自动管理生命周期，必须显式循环调用每个对象的析构函数；
• 用operator delete[](memory);释放内存，因为内存是通过operator new[]分配的，两者必须匹配。

内容的提问来源于stack exchange，提问作者Yousef Irshaid