std::move仅将左值转为右值引用，不实际转移所有权；真正转移由移动构造/赋值函数完成，原对象进入有效但未指定状态。
std::move 本身不转移所有权，只是转换为右值引用
很多人以为 std::move 会立刻“搬走”字符串内容，其实它只是把一个左值强制转成右值引用，让后续的移动构造或移动赋值函数有机会被调用。真正完成所有权转移的是 std::string 的移动构造函数或移动赋值运算符——前提是目标对象调用了它们。
常见错误现象：
– 写了 std::move(s) 但没接收到新对象（比如没赋值、没传参），原字符串依然可读且未清空
– 对 const 对象或字面量调用 std::move，编译失败（const std::string 无法绑定到非 const 右值引用）
- 必须配合接收方支持移动语义：如
std::string s2 = std::move(s1);或func(std::move(s)); - 移动后原对象处于有效但未指定状态（通常是空字符串，但标准不保证；可用
s.empty()检查，但不可依赖其值） - 不要对同一对象多次
std::move：第二次移动时可能操作已清空/无效的内部指针
移动构造 vs 移动赋值：行为一致但语义不同
两者都接管资源，但触发时机不同。构造是初始化新对象，赋值是替换已有对象的内容（后者会先释放原对象持有的内存）。
std::string s1 = "hello"; std::string s2 = std::move(s1); // 移动构造：s2 初始化，s1 留空 std::string s3; s3 = std::move(s2); // 移动赋值：s3 原内容被释放，接管 s2 资源，s2 留空
- 移动赋值后，被移动对象（
s2）仍保持有效，可安全析构或再次赋值；但不应再读取其内容 - 若目标对象已有大容量缓冲区，移动赋值可能复用该空间（取决于实现），而移动构造总是新建管理结构
- 在容器中 push_back 时，
vec.push_back(std::move(s))触发的是移动构造，不是赋值
什么时候不该用 std::move？
滥用 std::move 不仅没收益，还可能阻止返回值优化（RVO）或引发意外副作用。
- 函数返回局部对象时，直接
return s;即可，编译器通常自动应用 RVO 或移动；加return std::move(s);反而禁用 RVO - 参数是值传递（
void f(std::string s)）时，函数体内对s调用std::move没意义——它本来就是临时对象或已被移动过 - 对 string_view、const char* 等非拥有型类型调用
std::move是冗余的，它们不管理内存 - 在 for-range 循环中对元素
std::move：如果容器是std::vector<:string></:string>，循环变量声明为auto&& x才可能触发移动；写成auto x就是拷贝
检查是否真发生了移动：看 capacity 和 data 地址
移动成功与否不能只靠 empty() 判断，因为有些实现移动后保留小字符串优化（SSO）缓冲区，capacity() 仍非零。最可靠的方式是比对 data() 指针。
std::string a = "very long string that won't fit in SSO"; std::string b = std::move(a); std::cout
- 注意：SSO 字符串（短字符串）移动后，
data()可能不等——因为小字符串直接存栈上，移动只是位拷贝，不涉及堆指针转移 - 想确认是否避免了堆分配，可在移动前后用自定义分配器或 hook malloc 观察系统调用
- Release 模式下调试困难，建议在单元测试中结合 AddressSanitizer 验证移动后访问原对象是否触发 UAF 报告
移动真正的难点不在语法，而在判断“谁该拥有、何时释放、能否重用”。哪怕 std::string 实现得再完善，只要逻辑里存在共享预期或延迟销毁需求，盲目移动就容易出问题。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
