std::move仅是将左值转换为右值引用的类型转换，不执行移动操作；它使编译器允许调用移动构造/赋值函数，但若未定义则回退到拷贝，且移动后对象仅保证有效但状态未指定。
std::move 不是移动，只是类型转换
它不触发任何移动操作，只是把左值强制转成右值引用类型，让编译器知道“你可以搬走它”。如果对象没定义移动构造函数或移动赋值运算符，std::move 后仍会调用拷贝——这常被误认为“用了 move 就一定更快”。
常见错误现象：std::vector<int> v1(1000000); auto v2 = std::move(v1);</int> 看似快了，但如果后续又读 v1.size() 却没意识到 v1 已处于有效但未指定状态（通常是空），就可能引发逻辑错误。
- 只对明确不再使用的对象用
std::move，比如函数返回前、容器push_back临时对象时 - 不要对 const 对象用
std::move：const 左值无法绑定到非 const 右值引用，编译失败 - 移动后对象仅保证可析构、可赋值，不可假设其值或大小——标准只要求“valid but unspecified state”
什么时候用 std::move 能真正提速
核心看资源是否“可转移”：堆内存（std::vector、std::string）、文件句柄、锁等。内置类型（int、double）或小结构体移动和拷贝开销几乎一样，强行 std::move 反而干扰优化器。
典型场景：
立即学习“C++免费学习笔记（深入）”；
- 函数返回局部对象：
std::string make_name() { std::string s = "hello"; return std::move(s); }—— 实际上现代编译器通常自动 RVO，这里std::move多余 - 向容器插入临时对象：
vec.push_back(std::move(temp_str));避免字符串内部缓冲区拷贝 - 实现移动赋值运算符时：
other_ptr = std::move(rhs.other_ptr);把原始指针“掏出来”，再置rhs.other_ptr = nullptr
std::move 和完美转发的区别别搞混
std::move(x) 总是把 x 当作要搬走的右值；而 std::forward<t>(x)</t> 只在 T 是右值引用时才转为右值——这是模板参数推导 + 引用折叠的结果。混用会导致本该转发的左值被意外移动。
错误写法示例：
template <typename T>
void wrapper(T&& x) {
func(std::move(x)); // ❌ 所有调用都变成右值，丢失原意
}
正确写法：
template <typename T>
void wrapper(T&& x) {
func(std::forward<T>(x)); // ✅ 保持左值/右值属性
}
- 只在“你确定要放弃所有权”时用
std::move - 在通用模板里转发参数，一律用
std::forward - 编译器不会帮你检查 move 后是否误用，靠代码审查和运行时断言（如检查
ptr != nullptr）
移动语义失效的常见原因
写了 std::move 却没提速？大概率是移动语义根本没启用。最常见原因是类没声明移动特殊成员函数，或声明了但没定义（=default 或手动实现）。
- 若类含 const 成员或引用成员，编译器不会自动生成移动构造函数
- 若已定义了拷贝构造函数且未显式声明移动构造函数，编译器也不会生成移动构造函数（C++11 规则）
- 基类没提供移动操作，派生类默认也不会有——需手动委托或
=default - 用
-fno-elide-constructors编译时，RVO 关闭，std::move效果更明显；但生产环境应依赖 RVO + 移动语义组合优化
真正影响性能的是资源转移的可行性，不是 std::move 这个函数本身。它只是打开移动语义的钥匙，而钥匙能不能开门，取决于门后面有没有移动构造函数这把锁。
