移动构造函数必须显式定义以移交资源所有权，否则编译器生成的默认版本仅浅拷贝，导致如std::unique_ptr双重释放；参数须为MyClass&&并加noexcept，移动后源对象须置空指针等以达“有效但可销毁”状态。
移动构造函数必须显式定义才能转移资源所有权
编译器自动生成的移动构造函数是浅拷贝，不会真正移交资源控制权。比如你用 std::unique_ptr 封装堆内存，不写移动构造函数，std::move(obj) 后原对象仍可能持有非空指针，导致双重释放。
实操建议：
- 只要类里有独占资源（如
int*、FILE*、std::unique_ptr），就必须自己写移动构造函数和移动赋值运算符 - 移动后源对象必须处于“有效但可销毁”状态：比如把指针设为
nullptr，把文件描述符设为-1 - 移动构造函数参数必须是右值引用：
MyClass(MyClass&& other) noexcept，且强烈建议加noexcept，否则容器（如std::vector）扩容时可能退化为拷贝
std::move 只是类型转换，不触发移动操作
std::move(x) 本身不做任何资源转移，它只是把 x 强转成右值引用，让后续调用能匹配到移动构造/赋值函数。如果目标类型没提供移动接口，就会退回到拷贝——这时你可能以为“移走了”，其实还是深拷贝。
常见错误现象：
立即学习“C++免费学习笔记（深入）”；
- 对
std::vector<int>调用std::move(v)后又访问v[0]，没报错但行为未定义（标准只保证v.size() == 0或保持原大小，内容未指定） - 移动一个没有移动语义的自定义类，结果调用的是拷贝构造函数，性能没提升，还可能引发意外共享
- 在返回局部对象时忘了写
return std::move(local_obj)，编译器虽可能 RVO 优化，但 RVO 不强制，而移动语义是确定性保障
移动后访问源对象是未定义行为，但状态必须可析构
移动操作不是“清空”，而是“掏空再移交”。源对象仍是一个合法对象，能安全调用析构函数，也能再次赋值，但不能假设它还持有原来的数据。
使用场景与陷阱：
- 移动后立即对源对象调用
.get()（如std::unique_ptr）或解引用，属于未定义行为，编译器不报错，运行时可能崩溃 - 若移动构造函数里只做了
ptr_ = other.ptr_;没置空other.ptr_，那么源对象析构时会释放已被接管的内存，double free - 移动赋值运算符要先处理自赋值（
if (this == &other) return *this;），再释放当前资源，最后接管新资源
移动语义在容器操作中真正起效的条件
像 std::vector::push_back(std::move(x)) 能避免拷贝，前提是 x 类型支持移动，且容器元素类型是可移动的。否则退化为拷贝，甚至编译失败。
性能与兼容性影响：
-
std::vector<std::string>插入临时字符串时自动触发移动，比 C++11 前快得多；但若std::string编译时禁用了短字符串优化（SSO），移动才真正搬运指针 - 把移动对象传给接受
const T&的函数，不会触发移动——因为 const 左值引用能绑定右值，但阻止了移动语义的传播 - 返回局部对象时，优先靠编译器 RVO，其次靠移动；但若函数返回类型是引用或数组，移动语义根本不会参与
nullptr 赋值，就多一个悬挂指针的风险。 
