最稳妥禁用拷贝构造函数的方式是使用 myclass(const myclass&) = delete;，它在重载解析阶段报错、信息明确，且必须同步删除拷贝赋值运算符，否则仍可能引发语义错误。
直接用 = delete 禁用拷贝构造函数最稳妥
别写私有声明不实现，也别依赖友元或继承技巧——C++11 起，MyClass(const MyClass&) = delete; 是唯一推荐方式。它在重载解析阶段就报错，错误信息明确指向调用点，而不是链接时才失败。
常见错误现象：编译器报 use of deleted function ‘MyClass::MyClass(const MyClass&)’，说明某处（比如容器扩容、函数传值、临时对象绑定）触发了拷贝构造。
- 必须写在类定义内部，且参数类型要严格匹配：
const MyClass&和MyClass&是不同函数，删一个不影响另一个 - 如果类同时有移动构造，记得也显式
= delete或= default，否则编译器可能隐式生成移动函数，造成语义混乱 - 禁用后，
std::vector<myclass></myclass>会编译失败——因为 vector 扩容需拷贝或移动，而你只删了拷贝没管移动，结果既不可拷贝也不可移动
为什么不能只删拷贝构造，还得删拷贝赋值运算符
禁用拷贝构造不等于禁止所有复制行为。用户仍可能通过赋值操作（a = b;）意外复制对象，尤其在成员函数或模板推导中容易忽略。
典型场景：资源句柄类（如文件描述符、GPU buffer）若只删构造不删赋值，使用者写 handle2 = handle1; 仍能通过编译，但运行时可能 double-close。
- 必须同步声明
MyClass& operator=(const MyClass&) = delete; - 二者缺一不可；漏掉赋值运算符，
std::unique_ptr管理的类在 reset 时也可能触发隐式赋值 - 不要试图用
explicit替代= delete——explicit只防隐式转换，对拷贝本身完全无效
禁用后容器和智能指针怎么用
一旦拷贝被 = delete，类自动变成不可复制（std::is_copy_constructible_v<myclass> == false</myclass>），多数标准容器拒绝容纳它，除非你改用间接持有方式。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
错误示例：std::vector<myclass> v; v.push_back(MyClass{});</myclass> —— 编译失败，因 push_back 需要移动或拷贝元素。
- 改用
std::vector<:unique_ptr>></:unique_ptr>或std::vector<:shared_ptr>></:shared_ptr> -
std::move仍可用，但前提是移动构造/赋值也已正确定义（或未被误删） -
std::make_unique<myclass>()</myclass>没问题，因为它是直接构造，不涉及拷贝 - 注意：若类含不可默认初始化的成员（如引用、
const成员），编译器本就不会合成默认构造，此时额外= delete拷贝函数不会引发新问题，但也不会带来额外保护
最容易被忽略的“传染性”问题
禁用拷贝不是孤立操作。如果类 A 禁用了拷贝构造，而类 B 包含 A 类型的成员（A a_;），那么 B 的默认拷贝构造函数会被隐式删除——即使你没在 B 中写任何 = delete。
这个“传染”常在集成阶段暴露：B 对象被放入 std::vector 或作为函数参数传值时突然编译失败，错误提示却指向 B 的某个调用点，而非原始的 A 类定义。
排查时盯住错误信息里的函数签名，顺藤摸瓜找第一个含 = delete 的类成员；修复要么在 B 中显式定义拷贝逻辑，要么确保所有嵌套成员都支持所需语义。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
