std::move缺失会导致移动语义失效而退化为深拷贝，因具名变量默认是左值，不加std::move无法匹配T&&重载，只能调用const T&拷贝版本，引发堆分配与内存搬运的性能雪崩。
不加 std::move 本身不会“灾难性退化”，但会让移动语义彻底失效，退回到深拷贝——而你本以为它在移动。
为什么 std::move 缺失会导致拷贝而不是移动
移动语义的触发依赖两个条件：对象是右值，且目标函数有接受右值引用的重载。但一个具名变量（比如 temp_str、result）哪怕刚被构造出来，它也是左值。编译器不会自动把它当右值传给 push_back(T&&) 或 operator=(T&&)。
-
std::move的唯一作用就是把左值强制转成右值引用类型（T&&），让重载决议能选中移动版本 - 没它，就只能匹配
const T&拷贝重载——哪怕你写的是vec.push_back(temp)，temp是局部临时对象也不行（因为它是具名的） - 标准容器如
std::vector::push_back有两套重载：push_back(const T&)和push_back(T&&)；缺std::move就永远走前者
典型场景：vector 插入时漏掉 std::move 的实际开销
假设你有一个含堆内存的类 BigData（比如内部 new uint8_t[1024*1024]），并执行：
std::vector<BigData> vec; BigData temp = makeBigData(); // 构造完，temp 是左值 vec.push_back(temp); // ❌ 调用拷贝构造：malloc + memcpy + free
这会触发一次完整深拷贝。如果循环插入 10000 次，就是 10000 次堆分配 + 10GB 内存搬运（按 1MB/对象算）。而加了 std::move 后：
立即学习“C++免费学习笔记（深入）”；
vec.push_back(std::move(temp)); // ✅ 移动构造：仅交换指针，O(1)
耗时从秒级降到毫秒级——不是“快一点”，是数量级差异。
- 性能影响只对管理堆资源的大对象显著；
std::string在 SSO（短字符串优化）下可能看不出差别 - 如果类没实现移动构造函数，
std::move也无效，仍退化为拷贝（因右值可绑定到const T&）
更隐蔽的坑：返回值和成员赋值中忘记 move
这类错误更难发现，因为表面逻辑正确，但性能悄悄变差：
- 函数返回局部对象后，在接收端赋值时漏
std::move：m_data = getTempData();→ 走拷贝赋值，而非移动赋值 - 类内成员是
std::vector<bigdata></bigdata>，在移动赋值运算符里忘了对每个元素调用std::move：m_items[i] = std::move(other.m_items[i]);缺了这句，整个 vector 元素全拷贝 - 智能指针交接：
std::unique_ptr<t> p = createPtr(); m_ptr = p;</t>→ 编译不过（unique_ptr不可拷贝），但若换成shared_ptr，漏std::move就会多一次引用计数增减，看似小，高频下可观
为什么“灾难性”往往在压测时才暴露
开发阶段数据量小，拷贝开销不明显；一旦上线、并发升高、数据规模涨 10 倍，问题集中爆发：
- profile 显示
malloc、memcpy、delete占比异常高 - vector 扩容时大量时间花在旧元素搬迁上——本该是 O(1) 指针交换，却变成 O(N) 拷贝
- 关键路径延迟毛刺明显，且与数据量线性相关，不是常数抖动
最麻烦的是：代码能跑、结果正确、单元测试全过——它只是慢得离谱，而且慢得毫无征兆。
