必须手动定义拷贝赋值运算符以避免浅拷贝错误；需检查自赋值、先释放再分配资源、确保异常安全，推荐使用copy-and-swap惯用法。
拷贝赋值运算符怎么写才不会出错
不手动定义 operator=，编译器会生成默认版本——它只做成员逐个拷贝（bitwise copy），对含裸指针、文件句柄或动态资源的类几乎必然导致 double-free 或悬空指针。
正确实现要满足三个关键点：自赋值安全、强异常安全、资源正确转移。常见错误是漏掉自赋值检查，或者在抛异常前已释放了原资源。
- 先用
if (this == &other) return *this;拦住a = a; - 推荐“拷贝-交换”惯用法：接收
const T& other，在函数内构造临时对象，再和*this交换成员；交换操作应是 noexcept 的，且能天然避免自赋值问题 - 若手动管理内存，必须先
delete[] ptr;再ptr = new int[other.size];，不能反过来——否则异常时ptr成悬空指针
移动赋值运算符必须标记为 noexcept 吗
不是“必须”，但不加 noexcept 会导致 std::vector 在扩容时放弃移动而降级为拷贝，性能直接打骨折。标准容器依赖 noexcept 判断能否安全移动。
移动赋值的核心是“掏空对方”：把 other 的资源指针全设为 nullptr，避免析构时重复释放。它和拷贝赋值的逻辑完全不同，不能复用同一套代码。
立即学习“C++免费学习笔记（深入）”；
- 参数必须是右值引用：
T& operator=(T&& other) noexcept - 仍需自赋值检查：
if (this == &other) return *this;—— 因为std::move(a) = std::move(a);合法但危险 - 交换后记得把
other.ptr = nullptr;，否则other析构时会 delete 已转走的内存 - 若类有 const 成员或引用成员，无法移动赋值（编译报错），得考虑 redesign
拷贝和移动赋值一起出现时要注意什么
两者共存时，编译器按值类别精确匹配：左值走拷贝，右值走移动。但一个常见的坑是，只要定义了任意一个赋值运算符，编译器就不再生成默认的另一个——你得自己补全，否则 obj = another_obj; 可能意外调用拷贝构造（如果误写了构造函数重载）或直接编译失败。
更隐蔽的问题是“移动后使用”：移动赋值后的对象处于有效但未指定状态（valid but unspecified），只能安全调用析构函数或赋值操作，不能读取其值或调用其他成员函数。
- 确保移动赋值后，被移动对象的析构函数不会 crash（例如所有指针都置为
nullptr） - 如果类支持
swap()，优先用它实现两个赋值运算符，减少重复逻辑 - 使用
= default要谨慎：仅当所有成员都支持对应操作且无需额外清理时才安全；含std::unique_ptr可 default，含裸指针则不行
怎么验证你的赋值运算符真能工作
光编译通过没用。得测三类场景：自赋值、异常路径、移动后状态。尤其异常测试容易被忽略——比如在拷贝分配新内存时故意让 new 抛 std::bad_alloc，看原对象是否保持完整。
实际调试中，用 AddressSanitizer 配合 UBSan 最有效：它们能立刻捕获 double-free、use-after-move、未初始化读等典型错误。
- 写单元测试覆盖
obj = obj;、obj = std::move(other);、std::vector<t> v(100); v.push_back(obj);</t>（触发扩容移动） - 在移动赋值末尾加断点，检查
other.ptr是否为nullptr，再单步进其析构函数确认没 delete - 禁用编译器优化（
-O0）运行 ASan，否则某些 use-after-move 行为可能被优化掩盖
最常被跳过的细节是：移动赋值后对象的“有效但未指定状态”没有明确定义——你不能假设它等于默认构造值，也不能在未重新赋值前读取任何非 trivial 成员。这点在跨团队协作时特别容易引发 bug。
