MyClass() = delete; 是最可靠禁用默认构造的方式，它在重载解析阶段即报错，彻底阻断所有实例化路径，包括模板实例化、友元调用及继承场景，而 private 构造或依赖成员类型均存在绕过风险。
直接在类内声明 MyClass() = delete;，这是最可靠、最明确的方式。 其他做法（比如只设为 private、不写构造函数、或依赖成员类型“阻止合成”）都存在漏洞或不可靠边界，容易在集成时意外放行。
为什么 private 构造函数不等于禁止默认构造
仅将默认构造函数声明为 private，编译器仍可能为你合成它（尤其当类为空或所有成员都可默认初始化时），而且类内部、友元、静态成员仍能调用——这违背“禁止实例化”的本意。更危险的是：private: MyClass() = default; 这种写法看似限制了访问，实则主动触发了合成，外部虽不能调，但 static MyClass instance; 依然合法。
真正要阻断所有路径，必须让编译器在重载解析阶段就失败，而不是等链接或运行时。
-
MyClass() = delete;必须写在类定义内部，且不能带实现 - 若类已有用户定义的构造函数（如
MyClass(int)），编译器本就不会合成默认构造，此时再加= delete属于冗余但无害 - 若类含
const成员或引用成员，编译器同样不会合成默认构造——但别依赖这点做设计，因为一旦改成员，行为就变了
= delete 和成员类型“天然阻止合成”的区别
有人误以为“只要类里有 const int x; 或 std::string& ref;，编译器就一定不生成默认构造”，这是错觉。这种“阻止”只影响合成逻辑，不构成语义上的禁令：它只是让编译器放弃生成，而非拒绝调用。一旦你显式写了 MyClass() { } 或 = default，约束立刻失效。
立即学习“C++免费学习笔记（深入）”；
= delete 是主动、强制、不可绕过的声明，和成员类型无关：
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 即使所有成员都可默认构造，
MyClass() = delete;仍让MyClass obj;编译失败 - 错误信息直指函数被删除：
error: use of deleted function 'MyClass::MyClass()' - 模板实例化时（如
std::vector<myclass></myclass>）也会在实例化点立即报错，而非延迟到使用处
别漏掉 operator new —— 否则 new MyClass 仍能成功
只删构造函数还不够。C++ 中对象可通过直接 new 创建，而 operator new 是独立于构造函数的分配入口。如果没禁用它，new MyClass 或 std::make_unique<myclass>()</myclass> 仍可能通过编译（随后在构造时失败，但分配已发生）。
要彻底封死所有实例化路径，需同步删除分配器：
void* operator new(std::size_t) = delete;void* operator new[](std::size_t) = delete;- 若还支持 placement new 场景，也应考虑
void* operator new(std::size_t, void*) = delete;（通常不需要）
注意：一旦禁用 operator new，该类就不能作为 std::vector、std::list 等容器的元素类型——这不是 bug，是设计结果。
继承场景下，= delete 的传染性与 final 的作用
如果父类删了默认构造，子类定义时会因隐式调用父类构造而直接编译失败。这是好事，说明限制生效了。但如果你不希望子类绕过限制（比如通过继承后提供自己的默认构造），应在父类加 final：
-
class MyClass final { ... };→ 子类无法继承，从源头杜绝绕过 - 否则，哪怕父类构造被
= delete，子类仍可定义SubClass() : MyClass(...) { }，只要它能提供父类所需参数 - 友元类或模板代码中若出现
MyClass{}，也会在实例化点报错，但错误位置可能远离调用处，排查成本高
真正难缠的破口永远是友元和模板——它们能无视访问控制，也能触发对 = delete 函数的调用。所以，禁用构造函数不是“写完就完”，而是得通盘检查谁可能接触这个类的实例化意图。
