移动后原对象必须处于有效但未指定状态：可安全析构、可赋值，但值不可预测；std::move仅转换为右值引用，不执行移动；实现需满足标准约束而非强制清零。
移动构造后，原对象必须处于“有效但未指定状态”（valid but unspecified state），这是 C++ 标准的硬性要求，不是可选行为。
std::move 不等于“销毁”，而是启用移动语义的信号
std::move 本身不执行任何移动操作，它只是将左值强制转为右值引用，使编译器能匹配 Person(Person&&) 这类移动构造函数。真正决定原对象状态的是你写的移动构造函数体——标准只约束结果，不限制实现路径。
- 必须保证原对象可以安全调用析构函数：比如
delete[] ptr不能重复执行，指针应置为nullptr - 允许后续赋值：如
a = Person("new")必须合法，意味着移动后不能残留不可恢复的资源锁或句柄 - 禁止依赖其值：比如
a.size()或a.c_str()的返回值不可预测，a.empty()可能为true也可能不是（取决于你的实现）
常见错误：把“空壳”误解为“必须清零”
很多开发者误以为移动后必须手动把所有成员设成默认值（如 ptr = nullptr, size = 0），但这不是标准强制的。只要满足“可析构 + 可赋值”，哪怕 ptr 仍指向已释放内存（只要不再解引用）、size 是垃圾值，也合法——只是极度危险且不可维护。
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 标准库类型（如
std::string、std::vector）通常选择置空（empty()返回true），这是实现选择，不是规范要求 - 你自己写的类，如果资源释放逻辑复杂（如涉及文件描述符、GPU buffer handle），移动后保留句柄但标记为“已移交”，比盲目置空更安全
- 若移动构造函数可能抛异常，必须提供强异常安全保证：要么全成功，要么原对象回滚到移动前状态（这会退化为拷贝）
调试时如何验证移动后状态是否合规
最直接的办法是检查移动后对象能否被 std::swap、operator= 和析构安全调用，而不是试图读取其内容。
- 写一个单元测试：构造对象
a→ 移动构造b(std::move(a))→ 紧接着调用a.~T()（显式析构）→ 再调用a = T("fresh")→ 验证无崩溃、无 ASan 报告 - 避免在移动后做
if (a.size() > 0)这类判断——这不是 bug，而是设计缺陷：说明你本不该依赖该值 - 用
[[nodiscard]]标记移动构造函数无意义；真正该标记的是那些返回新对象、暗示原对象已失效的工厂函数
最容易被忽略的一点：移动后对象的“有效性”不传递给其子对象。比如你有一个 Container<t></t>，它移动了内部 T 成员，那么 T 的移动后状态由 T 自己保证，Container 不能假设 T 一定为空——除非你文档里明确写了这个契约。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
