移动语义通过移动构造/赋值函数交换资源指针而非深拷贝，避免临时对象多次堆分配；std::move仅是右值引用转换，不执行实际移动；自定义类实现移动操作须置空源指针、重置元数据、调用基类/成员移动，否则致崩溃或泄漏。
它能直接解决“临时对象被反复深拷贝”带来的性能浪费问题，尤其在容器操作、函数返回大对象、频繁构造销毁场景下，效果立竿见影。
std::vector.push_back() 时的三次拷贝是怎么来的
当你写 vec.push_back(loadConfig())，且 loadConfig() 返回一个含大量数据的自定义对象（比如内部持有一块 2MB 的堆内存），在没启用移动语义的老代码里，实际发生：
-
loadConfig()内部构造临时对象 → 一次堆分配 + 数据初始化 - 函数返回时，用该临时对象初始化
push_back的形参 → 调用拷贝构造函数 → 第二次堆分配 + 深拷贝 -
push_back再把形参 move 进 vector 底层存储 → 如果没写移动赋值，又触发第三次拷贝
而启用移动语义后，后两步会自动调用 T(T&&) 和 T& operator=(T&&)，只交换指针、长度、容量等几个字段，不碰原始数据内存。实测某配置加载场景，耗时从 18ms 降到 0.3ms。
为什么 std::move() 不是真的“移动”，而只是类型转换
std::move() 本身不做任何资源转移，它只是一个强制类型转换函数，作用是把左值表达式转成右值引用类型（即 static_cast<t>(t)</t>）。真正执行资源转移的是你类里写的移动构造函数或移动赋值运算符。
立即学习“C++免费学习笔记（深入）”；
常见误用：
- 对一个还在使用的变量调用
std::move()，后续再访问它 → 行为未定义（因为移动后源对象处于“有效但未指定状态”，比如std::vector的data()可能为nullptr） - 给没有实现移动操作的类调用
std::move()→ 编译器退化为调用拷贝构造，毫无收益 - 在返回局部变量时写
return std::move(local_obj);→ 多余，编译器本就会触发移动（或 RVO），加std::move反而可能阻止 RVO
移动构造函数里最容易漏掉的三件事
手写移动构造函数时，光“把源对象的指针拿过来”远远不够。必须同步处理：
- 将源对象的资源指针置为
nullptr（否则析构时会 double-free） - 重置源对象的 size/capacity/length 等元数据（否则
~T()析构时可能误判需释放） - 显式调用基类或成员的移动构造（
Base(std::move(other.base_))），否则它们会被默认拷贝
漏掉任意一项，轻则内存泄漏，重则 crash。标准库容器如 std::string 已内置完备实现，但自定义资源管理类（比如封装 FILE*、socket fd、GPU buffer）必须自己严格守规矩。
最常被忽略的点：移动操作不是万能加速器。如果类里只有几个 int 成员，写移动构造反而比拷贝构造更慢；只有当对象持有堆内存、文件句柄、大缓冲区等“可转移资源”时，移动才有意义。别为了“用新特性”而强行加 &&。
