std::move仅执行左值到右值引用的类型转换，真正移动由移动构造函数完成；若未正确“掏空”原对象（如置空指针），将导致二次释放等未定义行为。
std::move 不是移动，只是类型转换
很多人以为 std::move 会立刻搬走对象内容，其实它只做一件事：把左值强制转成右值引用类型（T&&），好让后续能匹配移动构造函数或移动赋值运算符。真正“移动”的动作发生在被调用的移动构造函数内部——如果那个函数没写，或者写了但没真正转移资源（比如忘了把原对象指针置空），那 std::move 就只是个无效的类型转换。
- 常见错误现象：
std::move后原对象还能访问、没崩溃，但逻辑出错（比如两次 delete 同一块内存）→ 很可能移动构造函数没清空原对象的裸指针 - 使用场景：函数返回局部对象、容器插入临时对象、swap 实现、避免深拷贝大对象（如
std::vector、std::string） - 参数差异：
std::move(x)对 const 左值无效（不能转成const T&&匹配移动函数），编译失败；对已定义移动语义的类才生效，对 int、float 等内置类型无意义
移动构造函数必须手动实现，且要“掏空”原对象
编译器生成的默认移动构造函数只在所有成员都可移动时才存在，且行为是逐个调用成员的移动构造——这看似省事，但一旦你管理了裸指针、文件句柄或自定义资源，就必须自己写，并确保原对象进入有效但未定义状态（例如把指针设为 nullptr）。
- 容易踩的坑：移动后仍用原对象调用析构函数 → 若没置空指针，二次释放 crash；或移动构造里只复制了指针却没修改原对象，导致浅拷贝
- 性能影响：没写移动构造，
std::vector插入大量自定义对象时会退化为深拷贝，O(n) 变 O(n²) - 示例：
class Buffer { public: Buffer(Buffer&& other) noexcept : data_(other.data_), size_(other.size_) { other.data_ = nullptr; // 关键：掏空 other.size_ = 0; } private: char* data_; size_t size_; };
std::move 在返回值和参数传递中用法不同
返回局部对象时，编译器通常自动启用 RVO/NRVO，std::move 反而可能阻止优化；但在函数参数中，传入右值引用形参时，必须用 std::move 才能把实参转为右值，触发移动语义。
- 常见错误现象：函数返回
return std::move(local_obj);→ 多余，且可能禁用 RVO；但func(std::move(obj));是正确用法 - 使用场景：
std::vector::push_back(std::move(x))避免拷贝；std::thread构造时传可移动对象（如std::unique_ptr） - 兼容性影响：C++11 起支持，但移动构造函数需标记
noexcept才能让std::vector在扩容时安全地移动而非拷贝（否则可能抛异常并回退）
移动后对象的状态只能用于析构或赋值，别再读写
标准只要求移动后的对象处于“有效但未指定状态”，意思是你可以安全地析构它、或给它赋新值，但不能假设它还保留原数据、也不能调用任何非 trivial 成员函数（比如 size()、data()）。
立即学习“C++免费学习笔记（深入）”；
- 容易踩的坑：移动后继续
if (obj.is_valid())判断 → 行为未定义；或移动后又传给另一个需要完整状态的函数 - 调试建议：在移动构造/赋值中加日志或断言，检查是否重复移动；用 AddressSanitizer 捕获 use-after-move
- 性能提示：移动不等于零开销——比如
std::string的 small string optimization 下，短字符串根本不会移动，而是直接拷贝；盲目套用std::move可能反而降低可读性
移动语义的复杂点不在语法，而在资源所有权的清晰边界。最容易被忽略的是：移动操作是否真正转移了控制权，以及后续对原对象的任何访问，哪怕只是读，都得先确认它是否还“拥有”那个值。
