移动后对象必须能安全析构，否则容器扩容等场景会崩溃；std::vector扩容时依赖移动操作的noexcept属性，若移动构造/赋值未声明noexcept则退化为拷贝；移动语义是移交所有权而非销毁源对象，要求移动后对象可析构且可赋值，典型错误是未置空已转移资源导致double-free。
移动后对象必须能安全析构，否则容器扩容等场景会崩溃
std::vector 扩容时依赖移动操作的 noexcept 属性
当 std::vector 容量不足需要扩容时，它会尝试将旧内存中的元素移动到新内存。但前提是移动构造函数或移动赋值运算符被标记为 noexcept —— 否则，标准库会退化为拷贝，以保障异常安全。如果移动后源对象无法析构（比如残留野指针、重复释放资源），哪怕只调用一次 ~T()，程序就会 UB。
- 移动操作若抛出异常，
std::vector::resize或push_back可能中途失败，旧内存已部分移动、部分未移动，状态不可恢复 - 标准只要求移动后对象“可析构 + 可赋值”，不要求保留原值，是因为这是最低成本的异常安全边界
- 典型反例：
Buffer(Buffer&& other) { data = other.data; }忘记置空other.data→ 后续other.~Buffer()释放已转移的内存 → double-free
移动语义不是“销毁源对象”，而是“移交所有权”
移动不是清空、不是重置、更不是析构前奏；它是把资源控制权从 A 交给 B，同时确保 A 仍是一个合法的 C++ 对象实例。C++ 标准不规定 a 在 auto b = std::move(a) 后的值，是因为它无法、也不需约束所有资源类型的行为（比如文件句柄关闭后是否还能 close() 两次）。
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 右值引用参数本身仍是左值（有名字、可取地址），所以移动构造函数体内对
other的任何访问都是合法的左值操作 - 常见做法是将原始资源指针设为
nullptr、句柄设为-1、size 设为0，这些动作本身不抛异常，且让后续析构/赋值有确定行为 - 如果类管理多个资源（如内存 + 文件描述符），必须全部移交或全部置为安全哑值，不能只处理一部分
std::move 不触发移动，只是类型转换
std::move(x) 只是把 x 的类型从 T& 转成 T&&，它不调用任何构造函数、不修改 x 的内容、不保证任何状态变化。真正决定对象状态的，是你写的移动构造函数或移动赋值运算符的实现逻辑。
立即学习“C++免费学习笔记（深入）”；
- 误以为调用
std::move就“已经移动了”，结果在后续代码里继续读x.data→ 未定义行为（可能为空指针解引用） - 编译器不会阻止你在移动后继续使用源对象，但标准不保证其值 —— 这意味着读取行为本身是危险的，哪怕看起来“没崩”
- 调试时容易忽略：移动后对象的成员变量值取决于你是否显式初始化它们，而不是编译器自动清零
最易被忽略的一点：移动后状态的有效性，最终由析构函数能否无副作用地执行来验证。哪怕你把所有指针都设为 nullptr，如果析构函数里还有未检查的 if (fd > 0) close(fd);，而 fd 没被重置，就可能 close(-1) 或 close(一个已被转移的合法 fd)。
