std::move不能自动让类可移动，因为它仅转换值类别，真正触发移动需类显式提供移动特殊成员函数；若声明拷贝操作或析构函数，编译器将不自动生成移动函数，必须手动删除拷贝操作、定义移动操作并避免抑制生成。
为什么std::move不能自动让类可移动
很多人以为只要写了移动构造函数，类就“天然可移动”——其实不是。std::move只是把左值转成右值引用，真正触发移动行为，得靠类自己提供匹配的移动特殊成员函数。而且，一旦你显式声明了拷贝构造函数或拷贝赋值运算符（哪怕只写个= delete），编译器就不会自动生成移动函数了。
所以，想实现“不可拷贝但可移动”，关键不是删掉拷贝函数就完事，而是必须：显式删除拷贝操作 + 显式定义移动操作 + 确保不意外抑制移动函数生成。
- 拷贝构造函数和拷贝赋值运算符必须都设为
= delete - 移动构造函数和移动赋值运算符要声明为
= default或手动实现（推荐= default，除非有资源接管逻辑） - 不要定义析构函数（或至少别让它成为用户提供的析构函数），否则会抑制移动函数的隐式生成（C++11/14 中尤其敏感）
= delete放错位置会导致编译失败
把= delete放在公有区却忘了加private？没关系，= delete本身就能阻止调用，访问控制不是重点。真正容易出错的是声明顺序和const限定不匹配。
比如，如果你写了MyClass(const MyClass&) = delete;，但没写MyClass(MyClass&&) = default;，那std::move(x)之后传入的右值仍无法绑定——因为没有可用的移动构造函数。
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 拷贝构造函数签名必须是
MyClass(const MyClass&)，删它就写MyClass(const MyClass&) = delete; - 移动构造函数签名是
MyClass(MyClass&&)，不能带const（否则无法修改源对象） - 赋值运算符同理：
MyClass& operator=(const MyClass&) = delete;和MyClass& operator=(MyClass&&) = default;
资源类中移动后状态必须明确
可移动不可拷贝的类，90%是管理独占资源的（如std::unique_ptr、文件句柄、socket）。移动之后，原对象处于有效但未指定状态——但你得让它“安全地无效”，否则后续访问可能崩溃。
例如，手动实现移动构造函数时，如果只是ptr = other.ptr;而不清空other.ptr，那两次析构就会 double-free。
- 用
= default最省心，编译器生成的移动操作对内置类型和符合规则的成员（如std::unique_ptr）是安全的 - 若需手动实现，移动后务必把被移动对象的资源指针置为
nullptr、句柄设为-1等明确无效值 - 析构函数里要能容忍这种“已移动”状态（比如先判空再
delete）
检查是否真不可拷贝：常见误判场景
你以为删了拷贝函数就万事大吉？不一定。有些情况会让拷贝“悄悄复活”：
- 基类有公有拷贝构造函数，而派生类没显式删除它 → 派生类对象仍可被拷贝（继承来的）
- 类模板中用了
default但没约束参数，实例化时因SFINAE绕过= delete（少见但存在） - 忘记删除拷贝赋值运算符，只删了拷贝构造函数 →
a = b仍能通过编译 - 使用
auto x = y;时，如果y是右值，可能触发移动；但若y是左值且没删拷贝，就直接拷贝了
最稳的验证方式：写个测试片段，显式尝试MyClass a; MyClass b = a;和a = b;，确认报错信息含deleted function字样。
移动语义不是银弹，它依赖你亲手把每一条拷贝路径堵死，并给移动留出干净出口。漏掉任何一个=delete，或者多写一个用户析构函数，都可能让移动失效或引发未定义行为。
