用 = delete 显式禁用赋值运算符是最安全、最明确的方式，需在类内 public 区域声明 operator= 并加上 = delete，可同时禁用拷贝和移动赋值，编译期报错，语义清晰。
如何用 delete 禁用默认生成的赋值运算符
直接在类内声明 operator= 并加上 = delete，就能阻止编译器自动生成、也禁止用户调用。这是最干净、最明确的方式，比私有化+不定义更安全（后者在友元或成员函数里仍可能被误用）。
常见错误现象：没删掉 operator=，但类里有 const 成员或引用成员，编译时报错 use of deleted function——其实是编译器试图生成但失败了，不是你主动禁用的。
- 必须写在类定义内部，且通常放在 public 区域（私有+
delete没意义，delete本身已足够表达意图） - 要同时禁用拷贝和移动赋值，就得分别声明：
T& operator=(const T&) = delete;和T& operator=(T&&) = delete; - 如果只删拷贝赋值但没删移动赋值，而类里又有不可移动成员，移动赋值也可能因编译器尝试合成而失败
为什么不能只靠私有化而不加 delete
私有化 operator= 能拦住外部调用，但拦不住类内成员函数或友元函数里的赋值操作；而 = delete 是硬性禁止，任何地方调用都会触发编译错误，语义更严格、意图更清晰。
使用场景：实现非拷贝资源句柄（如 std::unique_ptr）、单例管理器、或封装了裸指针/文件描述符等需显式转移语义的类。
立即学习“C++免费学习笔记（深入）”；
- 私有未定义的
operator=在 C++98/03 中常用，但链接期才报错，编译期无提示 -
= delete在 C++11 起支持，错误发生在编译期，位置准、信息明（例如：error: use of deleted function 'X& X::operator=(const X&)'） - 若类继承自基类，且基类的
operator=是deleted，派生类不会自动继承该删除状态，必须显式再次声明
禁用赋值后，哪些操作会受影响
禁用赋值运算符不等于禁用整个拷贝语义——构造函数是否可用取决于你是否也禁用了拷贝/移动构造。但一旦 operator= 被 delete，以下行为全部失效：
- 对象间直接赋值：
a = b; - 容器重分配时对元素的赋值（如
std::vector扩容时的元素搬移，若只删赋值但没删移动构造，可能退化为拷贝构造+析构，但多数标准库会直接拒绝容纳不可赋值类型） - 结构化绑定中涉及的隐式赋值（较少见，但某些解构场景会触发）
注意：std::vector<t></t> 要求 T 可复制赋值（或至少可移动赋值），否则 push_back、resize 等操作编译失败。若真需要存储不可赋值对象，得用 std::vector<:unique_ptr>></:unique_ptr> 或 std::deque（部分实现对不可赋值类型更宽容，但非标准保证）。
容易忽略的兼容性细节
模板类中条件性禁用赋值时，= delete 的声明必须依赖有效的 SFINAE 条件，否则会导致硬错误而非替换失败。比如想对 POD 类型允许赋值、非 POD 禁用，不能直接写 enable_if_t, T&> operator=(const T&) = delete;——这会在实例化时直接报错，而不是静默移除重载。
- 正确做法是用尾置返回类型 +
decltype或 C++20 的requires子句约束 - 聚合类（aggregates）即使没定义任何函数，只要成员都可赋值，编译器仍会隐式生成
operator=；所以禁用必须显式写出，不能指望“不写就等于禁用” - 如果类有用户定义的析构函数但没定义赋值运算符，C++11 起编译器也不会自动生成
operator=（即隐式删除），但这种隐式删除不如显式= delete清晰，也不适用于移动赋值
真正关键的是：禁用赋值不是孤立动作，它常意味着你要提供替代方案——比如显式的 clone()、swap() 或移动构造。否则使用者只会卡在编译错误里反复猜你到底想怎么传值。
