move语义是显式触发资源接管，std::move仅转左值为右值引用，真正移动由移动构造/赋值函数完成；原对象处于有效但未指定状态，需手动置空资源指针并标记noexcept。
move语义不是“把对象搬走”，而是显式触发资源接管
调用 std::move 本身不移动任何东西，它只是把一个左值强制转成右值引用类型，让编译器知道：“这个对象后续不再需要了，你可以安全地掏空它”。真正发生资源转移的，是接收该右值引用的移动构造函数或移动赋值运算符——前提是类自己实现了它们。
常见错误现象：std::move 后还能访问原对象？能，但行为未定义（比如访问已释放的指针）；std::vector 移动后大小为 0，但容量可能非零；自定义类没写移动函数，std::move 就退化成拷贝。
- 移动操作只对“拥有资源”的类型有意义（如含
new出来的指针、文件句柄、socket 描述符） - 基本类型（
int、double）和标准容器（std::string、std::vector）默认支持移动，但需确保编译器启用 C++11 或更高标准 - 移动后原对象处于“有效但未指定状态”：可析构、可赋值、可再次
std::move，但不能假设其内部字段仍可用
右值引用（T&&）不是“只能绑定临时对象”
T&& 是一种独立类型，它既能绑定纯右值（如字面量、函数返回的临时对象），也能绑定被 std::move 转换后的左值——关键看上下文是否允许“身份消除”。所谓“右值引用延长临时对象生命周期”，仅适用于直接初始化场景（如 const T&& r = T{};），不适用于函数参数转发。
容易踩的坑：void f(T&& x) { g(std::move(x)); } 中，x 是左值（有名字），必须再套一层 std::move 才能继续传递移动语义；而 auto&& 是万能引用，会根据初始化表达式推导为 T& 或 T&&，常用于完美转发。
立即学习“C++免费学习笔记（深入）”；
- 不要写
T&& t = some_lvalue;—— 编译失败，左值不能隐式转右值引用 - 要写
T&& t = std::move(some_lvalue);—— 显式转换，合法 - 函数模板中用
template+void f(T&& x) std::forward实现完美转发，避免移动语义在中间层丢失(x)
移动构造函数里忘记将源对象置为安全状态
典型错误是只做了资源指针的赋值，却没把原对象的指针设为 nullptr。这会导致双重释放：当两个对象（原对象和新对象）各自析构时，都尝试 delete 同一块内存。
class Buffer {
char* data_;
size_t size_;
public:
Buffer(Buffer&& other) noexcept
: data_(other.data_), size_(other.size_) {
other.data_ = nullptr; // 必须！否则 other 析构时 delete 空悬指针
other.size_ = 0;
}
~Buffer() { delete[] data_; } // 若 other.data_ 未置空，这里就崩了
};
- 移动构造/赋值函数应标记为
noexcept：否则std::vector在扩容时可能放弃移动而改用拷贝（影响性能） - 移动后原对象的字段只要满足“可析构、可赋值、不崩溃”即可，不必清零所有字段（比如
size_设为 0 是习惯，非强制） - 如果类中所有成员都支持移动（如含
std::unique_ptr、std::string），可直接 = default，编译器生成的版本已正确处理资源交接
什么时候不该用 move？
不是所有地方加 std::move 都有益。滥用反而破坏可读性、引入 bug，甚至降低性能。
- 返回局部对象时，优先依赖 NRVO（命名返回值优化）或编译器自动移动：直接
return obj;即可，不用return std::move(obj);（后者反而阻止 NRVO） - 函数参数已经是右值引用（
void f(T&& x)），内部再传给其他函数时，必须用std::move(x)，否则x是左值 - 对小对象（如
std::array、短字符串（SSO 模式下））移动和拷贝开销差不多，移动无意义，还可能因额外函数调用产生负优化 - 多线程环境下，移动后原对象若被其他线程访问，必须保证同步——移动语义不提供线程安全性
最常被忽略的一点：移动语义的价值不在单次操作快多少，而在避免不必要的堆分配与释放、减少缓存抖动、支撑高效的数据结构实现（如 std::vector::push_back 的扩容策略）。它不是语法糖，是现代 C++ 资源管理的底层契约。
