std::move仅是将左值转为右值引用的类型转换，不执行移动操作；它使移动构造/赋值函数得以调用，但若类型无移动语义或对象不可移动，则退化为拷贝。
std::move 不是移动，只是类型转换
std::move 本身不执行任何移动操作，它只是一个强制类型转换函数，把左值转成右值引用（T&&），从而让后续的移动构造或移动赋值函数有机会被调用。如果目标类型没有定义移动构造函数，或者你把它用在不支持移动的类型上（比如 std::Array），那仍然会走拷贝——编译器不会报错，但性能没提升。
常见误用现象：std::move 后继续使用原对象，结果访问到已“掏空”的内存（如 std::vector 的 data() 变为 nullptr）；或者对 const 对象调用 std::move，结果只能绑定到 const T&&，而多数移动函数不接受这个签名，最终退化为拷贝。
- 只对「可移动且你确定不再需要其值」的对象用
std::move - 移动后避免再读取原对象，除非文档明确说明该类型移动后状态可预测（如
std::unique_ptr移动后为nullptr） - 不要对返回值自动加
std::move：函数返回局部变量时，编译器通常会自动触发 RVO 或移动（c++17 起 guaranteed copy elision）
什么时候 std::move 真正提升性能
真正受益的场景集中在「资源独占型对象」：它们内部持有堆内存、文件描述符、线程句柄等昂贵资源，移动语义能避免深拷贝。典型例子包括 std::vector、std::String（小字符串优化除外）、std::unique_ptr、std::Thread。
反例：对 std::pair 或 std::array 用 std::move，几乎没差别，因为它们没有动态资源，拷贝就是 memcpy；过度使用反而干扰编译器优化。
立即学习“C++免费学习笔记（深入）”；
- 高频创建/销毁大容器时（如函数返回
std::vector<:string>） - 构建临时对象再插入容器：用
vec.push_back(std::move(temp))替代vec.push_back(temp) - 实现移动赋值运算符时，必须对成员逐个
std::move（如other.data_ = std::move(other.data_)）
std::move 在容器操作中的典型用法
STL 容器的插入接口（如 push_back、emplace_back、insert）有重载版本接受右值引用，此时传入 std::move(x) 可触发移动而非拷贝。但要注意：不是所有插入都值得移动——如果对象本身很小，或容器已预留足够空间，移动带来的指针交换优势可能被函数调用开销抵消。
std::vector v; std::string s = "hello world"; v.push_back(std::move(s)); // ✅ 移动：s 内部缓冲区指针直接移交 // 此时 s.size() == 0，s.data() 可能为 nullptr（取决于实现） -
emplace_back通常比push_back(std::move(x))更优，因为它直接在容器内构造，避免中间对象 - 对
std::map/std::unordered_map插入std::pair时，记得对 key 和 value 分别std::move，否则 pair 构造仍会拷贝 - 用
std::vector::resize扩容时，新元素默认构造，不涉及移动；但若用resize(n, value)，value 会被多次拷贝——此时应确保value是右值或轻量级
容易忽略的陷阱：移动后状态与 noexcept
移动操作是否 noexcept 直接影响容器行为。例如 std::vector::reserve 在扩容时，若元素的移动构造函数不是 noexcept，编译器必须提供异常安全回滚（即改用拷贝），这会让性能掉回原点。标准库中，std::vector、std::string、std::unique_ptr 的移动操作都是 noexcept 的，但自定义类默认不是。
- 自己写移动构造函数时，显式加上
noexcept（如MyClass(MyClass&&) noexcept） - 检查依赖的成员是否都支持
noexcept移动：若某个成员移动可能抛异常，整个类的移动也不能标noexcept - 用
static_assert(std::is_nothrow_move_constructible_v在编译期确认)
最常被忽略的一点：移动语义的价值高度依赖上下文。没有 profile 数据就盲目加 std::move，可能让代码更难读、更易出错，却换不来实际收益。