移动语义需显式调用std::move触发，它仅转换类型为右值引用以启用移动操作；未调用则默认走拷贝，且移动后对象处于有效但未定义状态。
移动语义不是自动开启的，得手动写 std::move
编译器不会因为你写了右值引用就自动帮你“搬走”资源——它只在你显式调用 std::move 时才把对象标记为可移动状态。没这一步，哪怕对象是临时的，也会走拷贝构造。
- 常见错误现象：
std::vector返回局部变量却没触发移动，内存反复分配 - 使用场景：函数返回大型对象（如
std::string、std::vector）、参数传递中避免深拷贝 - 注意：
std::move不移动，只是类型转换；它把左值转成右值引用类型，让编译器能选移动构造/赋值函数 - 别对同一对象多次
std::move：移动后对象处于“有效但未定义状态”，再次访问（比如再取.size()）可能崩溃或返回垃圾值
移动构造函数和移动赋值运算符得自己写，编译器不总给你生成
只有当类没有自定义析构函数、拷贝构造、拷贝赋值时，编译器才可能自动生成移动操作。一旦你写了 ~MyClass() 或 MyClass(const MyClass&)，默认移动函数就直接消失——这时候不手动补上，所有“本该移动”的地方都会退化成拷贝。
- 容易踩的坑：类里有裸指针或
FILE*等需要手动管理的资源，没写移动函数，结果资源被重复释放 - 参数差异：
MyClass(MyClass&& other) noexcept中的noexcept很关键——STL 容器（如std::vector::resize）在重分配时，只有移动操作是noexcept才敢用它，否则宁可拷贝 - 实操建议：移动构造里把
other的资源指针置为nullptr，避免析构时二次释放
std::move 用在返回值时，编译器可能优化掉（RVO），但别依赖它
RVO（返回值优化）和 NRVO（具名返回值优化）是编译器行为，不是语言保证。即使你写了 return std::move(local_obj);，某些编译器（尤其老版本 GCC/Clang）可能忽略它，或者在调试模式下干脆关掉优化，导致移动失效。
- 使用场景：写库函数或跨平台代码时，不能假设 RVO 一定发生
- 性能影响：加
std::move几乎零开销（只是类型转换），但漏掉可能导致 O(n) 拷贝变成 O(1) 移动的性能断层 - 兼容性提醒：C++11 起支持，但 C++17 起保证某些情形下强制 RVO（比如
return T{...};），不过仍建议显式std::move保持逻辑清晰
移动语义对 POD 类型无效，别白费劲
像 int、struct Point { int x, y; }; 这类纯数据类型，没有自定义构造/析构/赋值函数，移动和拷贝完全等价——都是 memcpy。强行套 std::move 不会提速，反而干扰阅读。
立即学习“C++免费学习笔记（深入）”；
- 常见错误现象：给
std::array<int></int>加std::move，以为能省时间，其实没差别 - 判断依据：看类有没有“管理资源”的行为（new/delete、fopen/fclose、pthread_create/join 等）
- 实操建议：优先对
std::string、std::vector、std::unique_ptr这类明确做了移动优化的标准类型用std::move，其他先查文档或源码确认
最常被忽略的一点：移动后对象的生命周期还在，但内容不可预测。有人在 std::move 后继续调用 .empty() 或 .data()，结果在不同编译器上表现不一——这不是 bug，是标准允许的未定义行为边界。
